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

471–480 of 491 posts

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

#471

Post by Zardoz84 »

netheril96 wrote: post #236
frozenport wrote: post #10

Earlier quoted context omitted.

On Windows "std::cout" can take upwards of 3ms. I noticed this when writing high speed camera software that was supposed to hit my callback every 2ms. Instead it was limited by my print statement! Does this emulator solve my problem?

Windows console is very slow (and terrible in many other ways). I think it is beyond salvageable. The only workarounds is probably write into a disk file or a pipe.

Try to use Cygwin + Mintty .

However, keeps being slower that any tty on any *nix. Sometimes fish autocomplete hangs for a few seconds when on the same machine running ubuntu fish autocomplete always is instantaneous. I don't know if it's related to something about the tty emulator or something weird on cygwin.

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

#472

Post by Zardoz84 »

ndesaulniers wrote: post #283
jwilm wrote: post #2

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

I love iTerm2 and hate tmux, but can't use iTerm2 on Linux. I greatly prefer iTerm's window splits and tabs to tmux's. Please reconsider.

Use Konsole

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

#473

Post by Zardoz84 »

chadcmulligan wrote: post #358
stuckagain wrote: post #351

Earlier quoted context omitted.

The problem is the terminals have been getting monotonically slower over the last 20 years, whereas the amount of build spew I need to grope around in to find the relevant error has not decreased :-/

yeah, I use ide's (Xcode/Appcode/VS/Delphi) for all my work so not really an issue. I can see if you're stuck with command line compilers though it would be annoying. I would hate to go back to make files and command lines ugh!

So you are missing a wonderful world of powerful tools because you not like terminals.

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

#474

Post by db48x »

lobster_johnson wrote: post #456
db48x wrote: post #411

Earlier quoted context omitted.

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.

It presumably doesn't feel like a hack to you because you're used to this mindset. To me, it's a deficiency in the lack of session management for SSH. All that SSH gives me is a two-way pipe to the other server's I/O. That's simple and elegant, but why does it create a new pipe every time? It's connection-oriented, which is a concept that hasn't seen any innovation since the 1970s. My preferred innovation here would…

Maybe you want eshell then:

    ~ $ cd /ssh:tol-eressea:.
    /ssh:tol-eressea:/home/db48x $ ls
    db48x.net  libvirt-sandbox  rpmbuild  zone.sh  zone.sh~  zone.txt  zone.txt~
If you've set ssh up to use control sockets then it can reuse existing connections.

MOSH is also nice; it decouples the program you're running from your connection, just like screen does, and it also uses udp instead of tcp so that it doesn't have to worry about dropped connections. Even your client's ip address can change and everything keeps working.

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

#475

Post by JdeBP »

db48x wrote: post #158
mistaken wrote: post #138

Earlier quoted context omitted.

cool project, but my question is why? rxvt is plenty fast for general purposes. if your bottleneck is the terminal emulator then you're doing something wrong. can you really read at ~10mbps?

No, of course you can't read all of the text at 10Mbps. The problem is that when you start some task which has a lot of spew, just having all of that text scrolling past can slow everything down to the point where the task actually takes longer! Even a few percentage points of slowdown can add up to minutes just sitting there twiddling your thumb. Just a few weeks ago I accidentally ran a command on a remote machine…

You think that your bottleneck is the terminal emulator, but you are wrong. As the mosh people pointed out a few years ago, the output from the remote machine has to scroll for 5 minutes because it is all backed up in the SSH connection between your machine and the remote one. Your bottleneck isn't in the terminal emulator at all, and changing terminal emulators to whizzy new ones will not make any difference to it.

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

#476

Post by JdeBP »

ericbb wrote: post #353
jwilm wrote: post #6

Earlier quoted context omitted.

Terminal performance is fine at smaller sizes and with less going on. In a multi-pane tmux window with vim, performance issues start to become noticeable. Many people I've talked to have experienced a situation where a bunch of output is being written to the screen, they panic to hit C-c, and then all you can do is wait for it to finish. This just isn't an issue with Alacritty. Alacritty is about having tools that do…

With the C-c issue specifically, I don't think that emulator throughput is the most likely culprit. It could be that the emulator is not handling inputs fairly: maybe it tries to process all available input from the pseudoterminal before processing the next batch of keyboard input. Or it could be that the pseudoterminal (kernel driver) is not configured to send the signal as expected. Or it could be that the process…

It isn't the most likely culprit. The mosh people point out that the place where people hit this is with a SSH session to another machine. Where the data are actually building up is the SSH connection. It's not a problem with the terminal emulators at all.

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

#477

Post by eridius »

JdeBP wrote: post #468
eridius wrote: post #153

Earlier quoted context omitted.

It's not as good as native scrollback though. For example, by default, as soon as you select something in tmux, the selection goes away, and you have to hit a tmux-specific keybinding to paste it back into the terminal. That's never what I want! If I'm selecting something it's probably because I'm going to copy it to my system keyboard. I think you can disable this part, except of course what you're left with at that…

Apple's Fn key isn't ideal. The USB HID usage ID is not one from the keyboard or consumer key pages. It's in one of the "vendor defined" pages, meaning that every keyboard driver supporting has to specifically recognize the device vendor and model, because without that context one cannot know what a vendor-defined ID means, and every new keyboard supporting this requires an operating system device driver update acros…

Huh, that's wacky.

Still, Das Keyboard has been making a Mac-specific keyboard for many years now, you'd think they'd at least reach out to Apple to see if they can get their keyboard recognized as having a Fn key (or, alternatively, provide a kext that adds support themselves). But the one time I asked them about it, they didn't seem to even care about how the Fn key behaves, so I doubt they've even made an attempt.

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

#478

Post by eridius »

zie wrote: post #317
eridius wrote: post #103

Earlier quoted context omitted.

Interesting, but I don't think I've ever felt the pain of not having that. It's pretty damn easy for me to use the global 1Password hotkey to bring up 1Password Mini, type a few characters to identify the login I want, hit → to expand the login, ↓ to select the password, and ↩ to then copy that password, which I can now paste into the terminal. It's not that hard.

with sudolikeaboss, it's hotkey, down arrow(↓) to the one you want, press enter(↩). A lot less keystrokes!

Unless you're entering your sudo password with every other command you type, it doesn't seem like it would make much difference either way, it's pretty darn fast already.

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

#480

Post by rogerbinns »

dustinkirkland wrote: post #458
rogerbinns wrote: post #215

Earlier quoted context omitted.

I'd be very happy if you more closely integrated with tmux and used the features from tmux instead transparently. I don't care how the terminal does scrollback, as long as it does. If you forwarded the scrolling commands to tmux then great. Same thing with tabs, panes etc. As much as I like tmux (although I exclusively use it via byobu), the single most annoying thing is that it won't let different viewers see differ…

In Byobu, you simply need to create a new session. Ctrl-Alt-F2. Then Alt-Up/Alt-Down to move among sessions. Each user can have their own session easily like this! Shift-F1 for the hotkeys, if you need a reminder ;-)

What would you know about byobu :-)

Ctrl-ALT-F2 would take a miracle to work. Shift does as you describe, but the net effect is still nowhere what is intended.

Also note I am the same user. The functionality I want is how byobu behaves with screen. eg you can start 3 xterms, in each one run byobu. And each one can jump around as they see fit all sharing the same screen session. No work, no fuss and exactly sane.

The tmux behaviour baffles me. I can't understand why anyone would want all their viewers to change in sync. Short of a classroom demo environment, it really doesn't make sense as a default.

I'd be delighted if by default byobu did whatever was needed to make tmux behave usefully.

Post reply on HN