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

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

blog.jwilm.io

Post reply on HN
Print view View original

431–440 of 491 posts

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

#431

Post by Anilm3 »

This is a very interesting concept and another example of what can be done with Rust. However and without the intention of discouraging the author, I did not find any performance improvement from Alacritty using Ubuntu 16.04 on an i7-4500U (using integrated graphics HD 4400). Here are some numbers, simply printing the contents of 446 files:

At 80x24:

gnome-terminal:

  real	0m0.848s
  user	0m0.032s
  sys	0m0.072s
Alacritty:

  real	0m6.832s
  user	0m0.032s
  sys	0m0.164s
At fullscreen:

gnome-terminal:

  real	0m0.819s
  user	0m0.020s
  sys	0m0.088s
Alacritty:

  real	0m8.972s
  user	0m0.064s
  sys	0m0.164s
The font was a tad smaller by default on Alacritty, changing it made no significant difference in the numbers. Since the difference in performance was quite noticeable I decided not to test other possible configurations, but I could do so if it might help.

My graphics card has a pretty poor performance in general so that might be an indication that, since the performance of Alacritty is directly impacted by the graphics card, it might be useful for the author to determine the "minimum requirements" for Alacritty to outperform the competition.

In any case, it might not be a fair comparison as the author has stated that this is a pre-alpha release, but maybe he can find it helpful in some way, as he suggests he hasn't been able to find a test in which Alacritty didn't perform as well as another terminal.

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

#432

Post by snowe_ »

martanne wrote: post #404
m45t3r wrote: 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. There are also simpler tools which can provide scrollback support. The whole Unix tty subsystem goes against the "Unix philosophy", that is why it was completely scraped in Plan 9.

Could you give me some reading to do? I had never heard of this before.

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

#433

Post by saghm »

pdkl95 wrote: post #382
saghm wrote: post #354

Earlier quoted context omitted.

> One thing I'm considering as a key-binding option is to exec a command. This would be pretty awesome. I definitely would love to have that as a feature, assuming it's not excessively difficult to implement.

You don't need to implement this in the terminal. You can bind macros to keys in anything that uses readline. Search for "inputrc" and the READLINE section in bash(1). While this is usually used for binding builtin functions (i.e. editing, history), you can simply provide the literal expansion. # in ~/.inputrc $if Bash # - find this with " {KEY}" "\e[24~": "sh \"${HOME}\"/path/to/swap_config.sh " # (the newline is in…

Thanks! Unfortunately I use zsh, and from a quick Google, it looks like it doesn't use inputrc.

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

#434

Post by steveklabnik »

jwilm wrote: post #321
steveklabnik wrote: post #278

Earlier quoted context omitted.

Couldn't you use get instead of [] for this? Maybe I'll look into it and send a PR :)

That seems completely reasonable. Not sure why I didn't consider it. PRs welcome :D

I figured out why: because there are two of them, it's a little awkward... I might have a PR for you, we'll see :)

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

#435

Post by clappski »

stuaxo wrote: post #408
dvhh wrote: post #403

Earlier quoted context omitted.

As a suckless terminal user I would say it is not the goal of the terminal emulator to provide scrollback, gnu screen or tmux are far better tools for that purpose.

Some people like using the mouse for scrollback, and the experience in tmux and screen isn't great by default.

In the case of tmux, it's only a single line change to activate mouse scrolling. It's nice to have the times when I switch over from a browser and instinctively try to scroll around.

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

#436

Post by greenspot »

jwilm wrote: post #2

I'm the author of Alacritty, and I'm here to answer any questions!

I want to encourage you to keep your product vision. It makes totally sense.

I am a heavy tmux + vim user, developing on a remote server. So, I have all my dev sessions always running and can access them on any client. I never needed scrollback or tabs in my terminal. tmux has it all. Excellent window and pane management + scrollback included.

And even on a remote connection I feel speed differences between terminal emulators as I wrote in another post. So, there is a strong need for such a product and great that somebody is innovating a console app in a time of locked-down fancy touch devices.

Well done and keep on going. Don't be intimidated by different requirements. Your product strategy is right (at least for me).

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

#437

Post by chriswarbo »

vidarh wrote: post #347
chriswarbo wrote: post #305

Earlier quoted context omitted.

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

If you want decoupling, look at the AmigaOS design: The console (terminal) consists of a bunch of independent elements: - Device drivers feeds raw input to input-handler - console.device manages a single console window. it receives raw input from the windows message port (courtesy of the input-handler) and "cooks" it into escaped character streams (which can include things like mouse reporting), and processes simple…

Thanks, that's really interesting. I grew up with Amigas exclusively until getting a family PC around 2000, although I didn't tend to use the CLI or do any programming back then.

I'm aware of BOOPSI, and the datatypes system which sounds similar to what you describe.

One problem on AmigaOS was(/is?) the lack of packaging and dependencies, e.g. installing many programs on a fresh copy of Workbench won't work, due to missing libraries, etc. Thankfully that's easier to manage these days by scouring Google and Aminet, but it's still manual.

Interestingly, I've found Amigas to become more stable over time, unlike e.g. Windows where some people recommend formatting every year or so to remove cruft. The more stuff you install in Workbench, the more libraries, etc. you accumulate, so the fewer problems you encounter trying to install/use other things. I'm not sure if this is a consequence of the OS design, or from developers bending over backwards to avoid problems (e.g. conflicting names, etc.)

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

#438

Post by Manishearth »

yarrel wrote: post #349
xxpor wrote: post #229

Earlier quoted context omitted.

>That's company policy Yes. I was just pointing out that regardless of modification/distribution/whatever, bigco policy is to not allow ANY AGPL code within a 10 mile radius of any computer owned by said company. The author(s) are free to use AGPL, but there are significant downsides if they care about adoption.

They care about the freedom of software users, not weird corporate policies. Non-adoption by non-respecters of freedom isn't a downside.

These aren't "weird corporate policies", they're very sensible. If they wish to use such software they need to be very careful in how, and track its use, and they just don't think having such a framework is worth it.

See https://news.ycombinator.com/item?id=13342657 , https://news.ycombinator.com/item?id=13342804

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

#439

Post by vidarh »

chriswarbo wrote: post #437
vidarh wrote: post #347

Earlier quoted context omitted.

If you want decoupling, look at the AmigaOS design: The console (terminal) consists of a bunch of independent elements: - Device drivers feeds raw input to input-handler - console.device manages a single console window. it receives raw input from the windows message port (courtesy of the input-handler) and "cooks" it into escaped character streams (which can include things like mouse reporting), and processes simple…

Thanks, that's really interesting. I grew up with Amigas exclusively until getting a family PC around 2000, although I didn't tend to use the CLI or do any programming back then. I'm aware of BOOPSI, and the datatypes system which sounds similar to what you describe. One problem on AmigaOS was(/is?) the lack of packaging and dependencies, e.g. installing many programs on a fresh copy of Workbench won't work, due to m…

Yes, BOOPSI was the model for the OOP used in AROS.

> One problem on AmigaOS was(/is?)

Is, sort-of. Package managers didn't enter the scene until much later, but Commodore did release Installer, which while not a package manager provides a s-expression based mechanism for describing installation flow.

It's alleviated because Amiga libraries tends to very strictly insist on backwards compatibility, so you should generally be able to drop a newer version of a library over an older version and things will keep working (and the libraries and all compliant binaries contains version numbers).

But of course the community today is very small, and was smallish originally too, and so it's gotten easier and easier to deal with.

If there was to be a resurgence (there is new hardware but it's expensive niche PPC hardware; AROS runs on pretty much "anything", but is incomplete), it'd need a lot of big overhauls - in particular memory protection (some work is ongoing but it's hard due to AmigaOS APIs relying a lot on pointer passing) and SMP, but also lots of tooling we take for granted today like package management.

I'm not holding my breath for that, but I do wish more AmigaOS ideas will get picked up elsewhere. Linux still feels like a hodge-podge in comparison.

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

#440

Post by hvis »

sjwright wrote: post #374
yarrel wrote: post #350

Earlier quoted context omitted.

Why?

You might be thinking of Lesser GPL? It should be immediately obvious why any Bigco would treat the AGPL like an exploding canister of infected blood and sharps. The AGPL treats web publishing as the same as binary distribution. If a bigco (e.g. Google) used AGPL code as part of a web service (e.g a web-based email client) there is a risk that they'd be required to comply with requests for source code. It's a pretty…

Why would you use notty's code inside a web service?
Post reply on HN