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

401–410 of 491 posts

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

#401

Post by stephen »

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

At some point, every application (browser, terminal, tmux, ...) re-implementing their own version of tabs is kind of silly.

Ideally "look at 'window' X of application Y" (where window == window / terminal tab / tmux pane / whatever) is what the local window manager should be used for.

E.g. instead of 1 tmux session with 4 tabs in it (or 1 terminal window with 4 tabs in it), I will run 4 mosh/tmux sessions (or 4 terminal windows) with 1 tab each, and use my regular window manager commands (i3) to switch between them.

In theory this is a better separation of concerns, and I can have one set of key bindings to do all window switching. Not:

1. Use window manager keys ctrl-foo to get to the right desktop/terminal window 2. Use terminal keys ctrl-bar to get to the right terminal tab with my tmux session in it 3. Use tmux keys ctrl-zaz to get to the right tmux pane

(Obviously a contrived example.)

...that said, I still use a crap load of tabs in Chrome, so theory != practice.

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

#402

Post by koyote »

Having never thought my current terminal emulator was slow I was surprised to immediately see a difference with Alacritty!

That being said, every time I install a package useing apt-get (Xubuntu) Alacritty crashes with the following: thread 'pty reader' panicked at 'index out of bounds: the len is 24 but the index is 18446744073709551615', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcollections/vec.rs:1371

I guess we're not quite at 1.0 yet but looking good otherwise!

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

#403

Post by dvhh »

sliken wrote: post #341
brandur wrote: post #80

I just want to say that this project is amazing. At the risk of sounding hyperbolic, I think Rust is the most exciting thing that's happening in computing today. This sort of project that plausibly replaces software traditionally written only in C/C++ with something that has performance parity, but is in a language where contributions are relatively accessible and safe, is the most exciting thing even within the boun…

I tried the terminal. No scroll bars, no menus, and no highlighting of URLs. Not nearly as functional as the original xterm from the early 90s. It might be super fast, but I've not really been scroll speed limited.

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.

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

#404

Post by martanne »

m45t3r wrote: post #231
arandomcoder wrote: post #180

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

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

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

#405

Post by martanne »

lobster_johnson wrote: post #200
arandomcoder wrote: post #180

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.

> A terminal app that has terminal features doesn't violate any principles of simplicity.

It still depends how these features are implemented.

For example in dvtm scroll back history is made searchable by piping it to $PAGER. Similarly, copy mode is implemented by using $EDITOR as an interactive filter.

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

#406

Post by ooqr »

i336_ wrote: post #400
gwu78 wrote: post #387

Earlier quoted context omitted.

"... generally infinite willingness to accept web apps..." Interesting. I stay in textmode. Hence I do not need an emulator. If I need graphics I access the files over VLAN from another computer designed for mindless consumption of graphics, like the locked-down ones they sell today with touchscreens, etc. My understanding is that emulators like xterm can redraw the screen faster than VGA. I remember this can make te…

The Web is two things. First, it's the promise that a certain runtime with a specific minimum set of capabilities is available almost anywhere. Secondly, it's a staggeringly-huge installed base of stuff written for that runtime. I don't think there's anything out there in the that matches the volume of deployed HTML, CSS and JS in the wild. The horribly sad part is that HTML, CSS and JS are a gigantic Rube Goldberg i…

Do you know of any forks or clean implementations of browsers which cut out legacy support more aggressively and/or are tuned for performance? Something like Chrome with less overhead because it doesn't bother to support deprecated features.

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

#407

Post by stuaxo »

barrkel wrote: post #357
sliken wrote: post #341

Earlier quoted context omitted.

I tried the terminal. No scroll bars, no menus, and no highlighting of URLs. Not nearly as functional as the original xterm from the early 90s. It might be super fast, but I've not really been scroll speed limited.

I generally use rxvt because xterm is too slow. It doesn't have menus or URL highlighting and scrollbars are nonfunctional in the presence of screen, tmux, Emacs or generally any interesting terminal app. On Windows I use mintty and I turn off scrollbars there. I simply don't use the mouse to interact with the terminal other than to select text, and that's with selection buffer to copy. Speed is highly relevant to me…

Interesting. For me, there isn't enough integration between the GUI and terminal ... they shouldn't seem separate, but should be bridged to create a coherent experience.

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

#408

Post by stuaxo »

dvhh wrote: post #403
sliken wrote: post #341

Earlier quoted context omitted.

I tried the terminal. No scroll bars, no menus, and no highlighting of URLs. Not nearly as functional as the original xterm from the early 90s. It might be super fast, but I've not really been scroll speed limited.

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.

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

#409

Post by i336_ »

ooqr wrote: post #406
i336_ wrote: post #400

Earlier quoted context omitted.

The Web is two things. First, it's the promise that a certain runtime with a specific minimum set of capabilities is available almost anywhere. Secondly, it's a staggeringly-huge installed base of stuff written for that runtime. I don't think there's anything out there in the that matches the volume of deployed HTML, CSS and JS in the wild. The horribly sad part is that HTML, CSS and JS are a gigantic Rube Goldberg i…

Do you know of any forks or clean implementations of browsers which cut out legacy support more aggressively and/or are tuned for performance? Something like Chrome with less overhead because it doesn't bother to support deprecated features.

Unfortunately there's currently nothing out there that generally meets all of the points you've touched on. There are some projects that tick one or two boxes, but not all of them.

Dillo parses a ridiculously tiny subset of HTML and CSS, and I used it to browse the Web between 2012 and 2014 when my main workstation was an 800MHz Duron. Yes, I used it as my main browser for two years. Yes, I was using a 19 year old computer 2-4 years ago. :P

Its main issue was that it would crash at inopportune times :D taking all my open tabs with it...

The one thing it DID do right (by design) was that the amount of memory it needed to access to display a given tab was largely isolated per tab, and it didn't need to thrash around the entire process space like Chrome does, meaning 5GB+ of process image could live in swap while the program remained entirely usable. This meant I could open 1000+ tabs even though I only had 320MB RAM; switching to a tab I'd last looked at three weeks ago might take 10-15 seconds (because 100MHz SDRAM) but once the whole tab was swapped in everything would be butter-smooth again. (By "butter-smooth" I mean "20 times faster than Chrome" - on a nearly-20-year-old PC.)

I will warn you that the abstract art that the HTML/CSS parser turns webpages into is an acquired taste.

---

Another interesting project in a significantly more developed state is NetSurf, a browser that aims to target HTML5, CSS3 and JS using pure C. The binary is about 3MB right now. The renderer's quality is MUCH higher than Dillo's, but it's perceptibly laggier. This may just be because it's using GTK instead of something like FLTK; I actually suspect firmly kicking GTK out the window will improve responsiveness very significantly, particularly on older hardware.

I have high hopes for this project, but progress is very slow because it's something like a 3-6 man team; Servo has technically already superseded it and is being developed faster too. (Servo has a crash-early policy, instead of trying to be a usable browser, which is why I haven't mentioned it.)

---

The most canonical interpretation of what you've asked for that doesn't completely violate the principle of least surprise ("where did all the CSS go?!?! why is the page like THAT? ...wait, no JS!?? nooo") would have to be stock WebKit.

There are sadly very few browsers that integrate canonical WebKit; the GNOME web browser (Midori) apparently does. Thing is, you lose WebRTC and a few other goodies, and you have to lug around a laundry list of "yeah, Safari doesn't do that" (since you're using Safari's engine) but I keep hearing stories of people who switch from Chrome back to Safari on macOS with unilaterally positive noises about their battery life and system responsiveness.

I've been seriously think-tanking how to build a WebKit-based web browser that's actually decent, but at this exact moment I'm keeping a close eye on Firefox. If FF manages to keep the bulk of its extension repository in functioning order and go fully multiprocess, the browser may see a bit of a renaissance, which would be really nice to witness.

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

#410

Post by db48x »

mistaken wrote: post #165
db48x wrote: post #158

Earlier quoted context omitted.

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…

yep: cmd &> /dev/null maybe? :) or ctlr-z; disown; exit... at any rate we're optimizing for edge cases

&>- would be faster, as long as we're at it.

But, the point is that sometimes it's a huge cost, and the rest of the time it's a tiny continuous slowdown.

Post reply on HN