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

481–490 of 491 posts

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

#481

Post by rogerbinns »

rogerbinns wrote: post #480
dustinkirkland wrote: post #458

Earlier quoted context omitted.

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…

A concrete example of what I mean. The user starts 3 xterms each running byobu with no additional parameters:

    for i in 1 2 3 ; do xterm -e byobu & ; done
Why would they want the view in each xterm to be identical, and why would they want changing the window (is that right terminology? pressing F3 and F4) in one xterm cause the other two to change in lockstep?

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

#482

Post by webmaven »

xxpor wrote: post #229
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?"

>That's company policy Yes. I was just pointing out that regardless of modification/distribution/whatever, bigco policy is to not allow ANY AGPL code within a 10 mile radius of any computer owned by said company. The author(s) are free to use AGPL, but there are significant downsides if they care about adoption.

> bigco policy is to not allow ANY AGPL code within a 10 mile radius of any computer owned by said company."

Wait, that seems extremely paranoid, even if only meant figuratively... Can you explain the thinking on restricting the use of AGPL'd licensed applications?

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

#483

Post by webmaven »

millstone wrote: post #375
kevin_thibedeau wrote: post #264

Earlier quoted context omitted.

You can still make modifications so long as it isn't distributed outside the company.

The problem is that "outside of the company" can be murky. What if the company outsources? What if the company hires contractors? What if the company employs an intern - does the intern now have the right to distribute the software? These are the legal landmines that BigCos want to avoid, mainly because they're questions that have not really been decided.

There are pretty simple As to these Q's. c

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

#485

Post by EnjoyTomato »

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…

Why do people still say C/C++? They are two different languages with different purposes and strengths/weaknesses. Rust might be a worthy competitor with C++, assuming many improvements down the line, but it's not even in the same category as C, no matter how much the enthusiasts like to claim otherwise.

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

#486

Post by dustinkirkland »

rogerbinns wrote: post #480
dustinkirkland wrote: post #458

Earlier quoted context omitted.

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…

Interesting... Frankly, I love the tmux default, to sharing the window, while also supporting the concept of "sessions". The shared view makes paired programming with a colleague across the world, while on the phone or a video conference super easy. Different users start in the same "session", and share the view of "windows" and "panes (aka splits)". If they want separate views/control, then they start separate sessions.

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

#487

Post by chadcmulligan »

Zardoz84 wrote: post #473
chadcmulligan wrote: post #358

Earlier quoted context omitted.

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.

I would argue the reverse :-). I've used terminals in the past, had the beauty that is screen, even gave courses on vi. When bitmapped screens became available it was ide's for me.

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

#488

Post by rogerbinns »

dustinkirkland wrote: post #486
rogerbinns wrote: post #480

Earlier quoted context omitted.

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…

Interesting... Frankly, I love the tmux default, to sharing the window, while also supporting the concept of "sessions". The shared view makes paired programming with a colleague across the world, while on the phone or a video conference super easy. Different users start in the same "session", and share the view of "windows" and "panes (aka splits)". If they want separate views/control, then they start separate sessi…

For your usecase I can understand. But when it is the same user using defaults it makes absolutely no sense. Why would they want separate xterms on the same display to be in lockstep by default?

Am I the only one who runs more than one terminal at a time? What happens now is I start an xterm on monitor #1 and start byobu within that. Various windows (whatever you switch amongst on pressing F3 and F4) are started - eg one might be client code running, one might be server code, one might be a database server etc. But sometimes for example I want to look at the client code output and server output simultaneously. At that point I switch byobu to the client window, and start a new terminal on monitor #2 and tail logs or whatever is appropriate. It is an annoying pain that I can't just run byobu and switch as I see fit.

In any event this is a multi-year frustration for me. People keep coming with convoluted workarounds (pointing tmux to tmux as far as I can tell) which it then isn't possible to figure out how to apply to byobu. All the while I wonder why two xterms running next to each other would ever want to be in lockstep by default?

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

#489

Post by quotemstr »

traverseda wrote: post #444
jwilm wrote: post #336

Earlier quoted context omitted.

> do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally? I hadn't replied to this because others had already provided all of the info I have. To summarize, the author of notty[0] and I are talking about a collaboration[1]. notty has done a ton of pathfinding in this area on identifying how to add many of these features in a backwards compatible way. I'm really lookin…

Is adding those features in a backwards compatible way really that important? Couldn't you just have a program send an escape code telling your term to go into "new" mode, and implement some completely different standard? Or I suppose use terminfo, but I like the idea of dealing with text streams better.

> Or I suppose use terminfo

What do you think terminfo does?!

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

#490

Post by fernandotakai »

kibwen wrote: post #290
fernandotakai wrote: post #257

Earlier quoted context omitted.

same. my tmux conf is really small (maybe 20 lines) and it does everything i want -- mouse support, vim keybinds, huge scrollback.

Can you paste that config somewhere for the rest of us to see?

https://gist.github.com/fernandotakai/57ef8b17e3f7428eeaa1bd...
Post reply on HN