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

461–470 of 491 posts

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

#461

Post by janekm »

xxpor wrote: post #142
dragonne wrote: post #92

Earlier quoted context omitted.

Another Rust terminal emulator project, notty[1], aims to do this. Downthread the author mentions that the projects are looking at collaborating. [1]: https://github.com/withoutboats/notty

It's too bad notty is licenced under the AGPL. That basically guarantees 0 usage at any sort of bigco.

I think you make a good point in this instance, so I upvoted. The follow-on discussion establishes the policy of big-cos pretty well and I don't think Alacritty much benefits from the AGPL since actual integration into other software base is unlikely (except for some of the sub-libs perhaps, but personally I feel that fundamental libraries flourish better under less-restrictive licenses anyway)

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

#462

Post by jwilm »

Anilm3 wrote: post #431

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

There's a known bug when using Mesa that kills performance. Hopefully we'll get it resolved soon!

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

#463

Post by __ddd__ »

__ddd__ wrote: post #460
jwilm wrote: post #446

Earlier quoted context omitted.

I'm happy to hear you're enjoying it! > concerning the the Alacritty devs since Alacritty requires a multiplexer to be usable The project initially started to be an optimized tmux renderer. It's not supposed to appeal to everybody. That said, there's a big segment of users with tiling window managers that are only blocked by not having scrollback, and we're talking about adding it. Features like tabs/splits will like…

I'm using Mint Mate (Sarah), can't get a context menu on right click. I installed all of the dependencies mentioned in the readme, though maybe Mint requires something that Ubuntu doesn't. Tmux mouse support works, interestingly enough. > Features like tabs/splits will likely never be introduced. I wholeheartedly support this. Count me among those that like the idea of an "optimized tmux renderer".

edit: I just realized you weren't referring to a context menu, but select/middle-click. Duh, didn't even think to try that as I don't really use that feature much. That'll do the trick for now, though apparently they plan to remove this feature from the next gnome release? Seems odd to me -- Anyways, thanks for the suggestion, now I can use alacritty for remote sessions!

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

#465

Post by sjwright »

_delirium wrote: post #451
Godel_unicode wrote: post #447

Earlier quoted context omitted.

This is the mindset that lead to people not realizing the impact of shellshock. If your webservice shells out to use any other tools (imagemagick for instance) the shell is now part of your app.

A shell could conceivably be used in a webapp's backend, but a terminal emulator is a lot less likely.

Which then begs the question why the author chose AGPL over regular GPL, if it's unlikely to ever apply in practice. What was the author worried about?

Meanwhile, it's much easier for a BigCo to have a blanket policy for a license which has incredibly high theoretical dangers and little clarity around its scope. And I don't blame them.

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

#466

Post by JdeBP »

vidarh wrote: post #343
jwilm wrote: post #160

Earlier quoted context omitted.

Thank you for the thoughtful comment. There's been a lot more pushback on the scrolling decision than I had anticipated. It's not something I want in my terminal, but it seems that a simple feature like this is essential for others. Perhaps I should reconsider. I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern. At least if we were to…

Scrollback support was added to AmigaOS ca. 1987 (with 2.04), and enabled on machines with 512KB RAM and a 7.xx MHz M68k CPU... Performance was not a problem then. Of course the highest resolution most people would run it on would be 640x512 back then, with typically 2 bit planes. But data volume has grown much less than CPU speed and memory bandwidth. Incidentally, AmigaOS' terminal design is worth exploring - it is…

The developers of the VTE widget had a problem a few years ago. The widget was using 16 open file descriptors per terminal emulation instance. This was causing problems for terminal emulator programs that had the architecture of a central server process that does all of the terminals on multiple X displays.

A GUI terminal emulator for such an architecture needs at least two open file descriptors, one for the connection to the X server and one for the master side of the pseudo-terminal. The other 14, it turned out, were being used by VTE's scrollback buffer mechanism, which involves writing data that have scrolled off the top of the screen out to (temporary) files.

They had managed to reduce this, by rearranging the structures of the scrollback files, to 8 open file descriptors per emulation by 2011, and reportedly it will be soon down to 4.

Interesting tidbit #1:

It was mentioned elsewhere in this discussion that the alternate screen on many terminal emulators has no scrollback. This is because the programs that switch between primary and alternate screens aren't actually doing that as far as they are concerned. They are switching between scrolling mode and cursor addressing mode (see http://superuser.com/a/715563/38062 for details), the latter not really having the concept of a negative row coördinate.

The VTE widget was using twice the number of open file descriptors, because both scrolling and cursor addressing modes had scrollback files.

* https://bugzilla.redhat.com/show_bug.cgi?id=667539

* https://bugzilla.gnome.org/show_bug.cgi?id=646098

* https://bugzilla.gnome.org/show_bug.cgi?id=738601

* https://bugzilla.gnome.org/show_bug.cgi?id=741520

Interesting tidbit #2:

LXTerminal has this single centralized emulator process architecture, too. It has a rather nasty open file descriptor leak with which one can render LXTerminal completely unusable in about 1 minute (if one has an open file descriptor limit of 1024).

* http://unix.stackexchange.com/a/333578/5132

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

#467

Post by sjwright »

wpietri wrote: post #427
yarrel wrote: post #349

Earlier quoted context omitted.

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

It's a downside if it leads to general non-adoption, either directly or because a competitor with a different license gets the market share. I'm all for the moral stance, but moral purity in a vacuum is essentially irrelevant. Effective morality is about impact on the world. A morality that's only about the good feelings of the purist is sterile self-indulgence.

Precisely. And even RMS has been known to agree with that principle.

http://lwn.net/2001/0301/a/rms-ov-license.php3

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

#468

Post by JdeBP »

eridius wrote: post #153
GrinningFool wrote: post #120

Earlier quoted context omitted.

tmux does provide full scrollback with mousewheel support too. # Enable mouse support including scrolling set -g mouse on # Versions prior to 2.1 may want this too: set -g mouse-utf8 on history-limit 5000 # 5000 lines of history per pane. Adjust as needed.

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 across many operating systems as well as system firmware updates to machines whose firmwares recognize this vendor-defined ID as a keyboard key, all to add another vendor ID in to the drivers' lists of "this vendor+device has Apple's Fn key".

* http://lxr.free-electrons.com/source/drivers/hid/hid-apple.c...

* https://bugs.launchpad.net/ubuntu/+source/linux/+bug/942184

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

#469

Post by Zardoz84 »

GrinningFool wrote: post #31
dom0 wrote: post #24

Earlier quoted context omitted.

I've done that (we all did), but "can't reproduce". So this seems to depend a lot on the emulator, eg. I'm using Konsole, which is superb, and don't see that problem there.

Konsole is the only emulator I've used (other than actual tty) that doesn't have this problem. It's actually been frustrating, becasue there is plenty about it that I don't like. I'll be giving Alacritty a try shortly - if it does what it says on the tin, it's exactly what I've been looking for.

Add to the mix Yakuake. It uses Konsole inside.

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

#470

Post by Zardoz84 »

GrinningFool wrote: post #457
dom0 wrote: post #86

Earlier quoted context omitted.

Curious: What don't you like about Konsole?

The only real issue I run into is clipboard wonkiness when console apps integrate the clipboard (nvim+twmux). Beyond that, it has a ton of features - none of which I use since I manage my sessions with tmux. So I guess it's mostly a matter of not wanting a sledgehammer when the right tool is a finishing hammer?

I use nvim inside Konsole/Yakuake and I don't have any issue with the clipboard. "+p and "+y works fine Also Shift+Inst and Shift+Supr keeps working fine.
Post reply on HN