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

231–240 of 491 posts

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

#231

Post by m45t3r »

arandomcoder wrote: post #180
netheril96 wrote: post #174

Earlier quoted context omitted.

> Performance with large amounts of output is also a concern. Frankly, removing two very important features for a lot of people (me included) and then claiming highest performance feels a bit like cheating.

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

> 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, because it applies differently for different people.

For example, I use i3, that is a tilling window manager, so I don't need tabs or split management for tmux. Actually, I removed tmux since I started to use i3 because using i3 features feels much more natural, since they apply to every window. However, there is only one thing that I can't have with i3 that is scrollback buffer, so while I don't need a terminal with tabs, I need support for scrollback buffer. Adding tmux just to get scrollback goes against Unix philosophy.

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

#232

Post by netheril96 »

smegger001 wrote: post #220
lobster_johnson wrote: post #162

Earlier quoted context omitted.

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

or you could type CTRL+Z BG

And that will still send the program SIGUP, killing it when you close the terminal or lose your ssh session.

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

#233

Post by guitarbill »

rocqua wrote: post #193
atombender wrote: post #136

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…

> Solutions like tmux arguably exist because terminals have poor UIs Whilst I totally agree with you, I think Tmux is a lot like vim in its power. Along the same note, I'd wager a gTmux, much like gVim would be q real nice way to multiplex terminals when we get the UI to beat the TUI.

I mean Terminator is basically gTmux, right? They aren't quite the same: tmux is a terminal multiplexer, Terminator is a terminal emulator with tabs and panes. Both approaches have benefits and drawbacks.

If you want keyboard only, I don't think GUIs can beat TUIs. But yeah, there's a learning curve.

The problem with GUIs is a very display-session centric view. tmux/vim work fine over SSH, Terminator/gVim don't. With tmux, your sessions are separate from your terminal instance. If your X session crashes, depending on how you started tmux, you just have to relaunch a terminal and reconnect to tmux. This is pretty invaluable. So this separation is powerful, and IMO very Unix-y.

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

#234

Post by qb45 »

smegger001 wrote: post #220
lobster_johnson wrote: post #162

Earlier quoted context omitted.

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

or you could type CTRL+Z BG

Still can't reattach after logout/reconnect, which is a very common screen/tmux use case.

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

#235

Post by atombender »

twic wrote: post #222
lobster_johnson wrote: post #200

Earlier quoted context omitted.

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

That particular example of find not needing to sort persistently annoys me. sort doesn't know anything about the structure of its input, so it has to read and buffer all of it before it can sort it. find knows that its input is a tree of strings, which it could exploit to produce sorted output at the cost of buffering one directory's worth of filenames at each level of the tree. It's rarely a significant problem in p…

To avoid cluttering "find" with a sorting interface, we could use the modern technique processing push-down:

If you do "blah | sort", then "sort" could ask its upstream processing node whether it supported sorting on the requisite fields, and "push down" the necessary sort-order descriptor into the "blah" step.

That requires two things: That the pipe API sets up a communications channel between the two programs in a way that makes them aware of each other and able to exchange information; and secondly, that the pipe protocol is based on typed, structured data. I want both things.

Imagine if you had that, then you could conceivably also do:

    psql -c "select firstname, lastname from foo" |
      sort -f lastname
and psql would automagically rewrite its query to:

    select firstname, lastname from foo order by lastname
That's the future I want to live in, anyway.

The inability to do this sort of thing really a product of a failure to modernize the 1970s text-oriented pipe data model. I believe PowerShell (which I've never used, only read about) provides a mechanism to accomplish this sort of thing, at the expense of being extremely Microsoft-flavoured.

I don't think there's anything even vaguely scifi about those abilities, but the Unix world is hampered by a curious reticence to innovate certain core technologies such as, well, Unix itself. That's why we still have tmux and such.

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

#236

Post by netheril96 »

frozenport wrote: post #10
h4nkoslo wrote: post #3

Earlier quoted context omitted.

Cool project, but I have literally never thought a terminal was excessively low-performing enough to prevent work from getting done. What applications benefit from a terminal that's even an order of magnitude faster than the alternative?

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.

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

#237

Post by guitarbill »

shmel wrote: post #172
WhatIsDukkha wrote: post #95

I really disagree with the authors definition of minimal. Terminal emulators have such a minimal user interface as it is it's a bit boggling that I have to make the case for the following "bloat" that other terminal emulators have. I need scrollback because I do occasionally pick up my mouse and grab things that have scrolled off the screen. Tmux doesn't help with this but maybe there is some magic that I don't know…

I switched to tmux a few years ago and never looked back. What is your problem with mouse? I have quite basic tmux config, very basic terminal emulator (st) and enjoy mouse scrolling even in nested tmux scenarios. Selection is done with vim keybindings which is much faster than mouse especially if you scroll and look for something visually. I can relate to your feelings. In the beginning I was _very_ skeptical about…

> The only bad thing I remember: default tmux keybindings suck. I just redefined almost everything.

It's true, e.g. ^B / Ctrl+B is a terrible prefix. All of this just makes tmux harder to learn, and less portable/transferrable. But I think there's value in having to feel out the ideal configuration for your workflow - but the prefix is still inexcusable.

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

#238

Post by nopreserveroot »

dekhn wrote: post #218
nopreserveroot wrote: post #207

Earlier quoted context omitted.

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.

See EDIT2 on my post.

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

#239

Post by imsofuture »

jwilm wrote: post #210
Florin_Andrei wrote: post #25

Earlier quoted context omitted.

> and scrollback are unnecessary Um... that's kind of a deal breaker to me. Really no scrollback at all?

I may be reconsidering this position[0]. If scrolling support can be added in a non-intrusive way behind a feature flag (so it could be completely compiled out), it could potentially have a place in Alacritty. [0]: https://news.ycombinator.com/item?id=13340369

Sounds great! I totally understand the motivations behind the decision to leave it out, but it's a great candidate for a compile time flag. I would love to throw out gnome-terminal for this!

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

#240

Post by coldtea »

>tabs and scrollback are unnecessary. The latter features are better provided by a terminal multiplexer like tmux.

I beg to differ. I don't really know whenever there's a project that's almost perfect, there's some braindead decision that cripples it with no good reason.

I'd understand it if some more advanced or exotic feature wasn't available, but scrolling?

Post reply on HN