Live data from Hacker News

Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

blog.jwilm.io

411–420 of 491 posts

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#411
post #152

Earlier quoted context omitted.

Have you heard of nohup?

Sure. But nohup doesn't work for shells or anything interactive. You can't attach to it.

Ok, so you're interactively using a program on a remote server and you don't want it to die if you lose your connection? Screen isn't a hack in that case :)

Although you could ditch it and use MOSH instead.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#412

How do they define performance, and how do they measure it?

FPS or more strictly, DUPS (display updates per second), as a function of resource use - that is, what pushes the most text, the fastest, with the most displayed frames (sent to actual display/monitor) corresponding to discrete states of display output (v vis-à-vis the terminal), per second?

Some terminals bottleneck standard out ️ display , some hardcode the display rate

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#414

Not sure why they rebuilt a clipboard library when "clipboard" exists (I think it might even be used within Servo, not sure): https://crates.io/crates/clipboard

> A non-GPL licensed cross-platform clipboard library, (That is, that project is GPL licensed, and they didn't want that)

Oh, I thought "clipboard" was dual licensed to GPL and/or Apache 2.0. My bad. I hadn't seen that the x11 related code was purely GPL 2.0.

Thanks for your help, Steve !

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#415
post #231

Earlier quoted context omitted.

> I respectfully disagree. Alacritty follows the Unix philosophy of doing one thing, and doing it well. I used to think that terminal scrollback and tabs were great ideas -- but switching to tmux changed my mind completely. Tmux is so much more capable for managing your session history. The terminal's tab and scrollback features can never match this. They're just bloat :p This is the problem of Unix philosophy, becau…

> Adding tmux just to get scrollback goes against Unix philosophy. I agree. Rather than adding scrollback support to allacritty, maybe someone could write an independent program for scrollback support (a la dtach/abduco for detaching/reattaching)? Such a program would be useful for all terminals which lack scrollback (alacritty, st, possibly others). For the record I use st with dtach and dvtm; scrollback is supplied…

100% agree, to the best of my knowledge there exists no tool that adds scrollback support to a terminal emulator without doing anything else. My solution now is to use tmux for this, but it is not really elegant. Piping everything through less is not an option :P

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#416
post #60

Earlier quoted context omitted.

> Personally, the lack of scrollback and tabs is a dealbreaker for me Completely understandable. This decision was expected to be polarizing. > Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux. Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone.

I like opinionated software. If scrollback is better implemented on a different layer, leaving it out is reasonable. But I'm not using tmux because I use i3 as wm which does all the tiling/splitting. Now using a new tmux instance for each of my terminal (can be dozens) only for scrollback seems not the right way though. Any recommendations what would be The Right Way here? Anything that only implements scrollback may…

I'm also using i3wm (and currently terminology as terminal). I'd love to give alacritty a try but not without proper scrolling :(

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#417

Earlier quoted context omitted.

> You do seem overly excited. :) Hah, yeah I'm aware, but the potential of Rust is huge. We talk a lot about open source these days, but meanwhile the tools that we all use are sitting on huge substrates that the vast majority of us aren't contributing to and probably never will due to the complexity hurdle that needs to be overcome. This includes our web browsers, our terminals, our editors/IDEs, our operating syste…

Isnt most of your points just the relative newness of rust? I could rewind a few years, replace [rust] with other platforms like [node] or [erlang] and the same statements apply. I'm not disagreeing with you, I'm just pointing out that it seems to be the stage an a natural progression of platforms.

Why was erlang "hot" for you a few years ago?

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#418
While GPU accelerated 3D interfaces (like it in 3D games) is a good idea (at least one could mix data visualization and with controls - the way WebGL guys do it) a terminal emulator does not require any acceleration, leave alone having a Nvidia drivers or Cuda as a dependency.

What a decent terminal emulator should have is standard compliance and decent font rendering (and freetype is good-enough).

Lousy engineering will lead to lousy code, especially when the main objective is to show off (engineering is, obviously, not an objective.) Btw, using Rust is not an engineering.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#419
post #418

While GPU accelerated 3D interfaces (like it in 3D games) is a good idea (at least one could mix data visualization and with controls - the way WebGL guys do it) a terminal emulator does not require any acceleration, leave alone having a Nvidia drivers or Cuda as a dependency. What a decent terminal emulator should have is standard compliance and decent font rendering (and freetype is good-enough). Lousy engineering…

Everything that can be GPU-accelerated should be GPU-accelerated. The GPU is far more energy efficient, and every bit of offload onto the GPU leads to a decrease in CPU consumption. Terminals can be particularly CPU-heavy when running a chatty program.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#420
post #418

While GPU accelerated 3D interfaces (like it in 3D games) is a good idea (at least one could mix data visualization and with controls - the way WebGL guys do it) a terminal emulator does not require any acceleration, leave alone having a Nvidia drivers or Cuda as a dependency. What a decent terminal emulator should have is standard compliance and decent font rendering (and freetype is good-enough). Lousy engineering…

Everything that can be GPU-accelerated should be GPU-accelerated. The GPU is far more energy efficient, and every bit of offload onto the GPU leads to a decrease in CPU consumption. Terminals can be particularly CPU-heavy when running a chatty program.

I hope systemd guys will read this.
Post reply on HN