Live data from Hacker News

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

blog.jwilm.io

211–220 of 491 posts

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

#211
post #134
post #2

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

This looks like an awesome project! You mention tmux, what about GNU Screen? does it work as well? I don't remember major perf issues using vim within screen, I'm afraid to use Alacritty and then never be able to come back to my past setup :)

From what I understand, screen should be roughly equivalent. I mention tmux because it's my multiplexer of choice.

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

#213
post #98

A pity you can't use Vulkan on MacOS. Otherwise you could have used vulkano[1] instead of OpenGL. 1. https://github.com/tomaka/vulkano

Even so, I do plan to add a Vulkan renderer at some point using vulkano. My hope is that the build script can choose the best option at compile time.

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

#214
post #202

Earlier quoted context omitted.

The AGPL is different from the GPL. The AGPL prevents use at my Bigco (Google) for a number of good reasons.

That's company policy and not the fault of the license. EDIT: Unless you're making modifications to the software, the AGPL does not apply. EDIT2: http://www.affero.org/oagf.html#How_does_this_license_treat_... Specifically, the question, "How does this license treat commercial enterprise use over intranets and internal networks?"

Is that true? My understanding of the AGPL was that any software product which uses it as a component becomes subject to the AGPL - it has the linking semantics of the GPL, not the LGPL. If that's not the case, please do disabuse me of my misconception!

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

#215
post #160

Earlier quoted context omitted.

> Features like ... are better provided by a terminal multiplexer I would strongly argue that this thinking is putting the cart before the horse. I don't use tmux, nor do I want to (though occasionally I have to use screen as a hack to keep programs running on remote servers, and I hate every second of it). Solutions like tmux arguably exist because terminals have poor UIs, and the terminal protocol is too weak to fo…

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…

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 different content. (eg start two terminal emulators, run tmux in both and any switching you do in one affects the other. There are supposedly elaborate workarounds, but far too much effort.)

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

#216

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

> Alacritty follows the Unix philosophy of doing one thing, and doing it well. That principle is often misapplied, and I think that's true here, too. The "do one thing" about Unix is really about composability (e.g. "find" doesn't need to sort because you do "find | sort"), but you don't compose a terminal app with anything. A terminal app that has terminal features doesn't violate any principles of simplicity.

PuTTY does lot of things. PuTTY is good solution for world of Windows, but alien in world of UNIX. "Do one thing" rule applies to terminals too.

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

#217

How much unsafe code was needed to make this work?

As Steve mentioned, it was mostly for ffi. There's also a few places where I'm doing my own bounds checking in order to provide nicer error messages. After doing the bounds checking, doing an index operation without the standard library's bounds checking requires unsafe.

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

#218
post #202

Earlier quoted context omitted.

The AGPL is different from the GPL. The AGPL prevents use at my Bigco (Google) for a number of good reasons.

That's company policy and not the fault of the license. EDIT: Unless you're making modifications to the software, the AGPL does not apply. EDIT2: http://www.affero.org/oagf.html#How_does_this_license_treat_... Specifically, the question, "How does this license treat commercial enterprise use over intranets and internal networks?"

I think your understanding of the AGPL (specfically) is in error.

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

#219

Earlier quoted context omitted.

Don't worry. The Rust community is sensitive to the desire to only install Rust with a package manager. There was even talk (a few days ago) of making an LTS version of the Rust compiler for use in more conservative distros that don't want to update it every 6 weeks. On another front, Rust is working hard to get people off of nightly. This project, for example, uses 3 unstable features. Clippy can already work on sta…

> Clippy can already work on stable No. But we plan to make it work.

Sorry Manish, I had meant that you can have code that can be built using a stable compiler while still using Clippy via another means. I typically use stable, but I run clippy on my code anyway. I realize that my post is confusing, I'll edit.
Post reply on HN