So it is mosh, but much better? I'll try it.
The PPA doesn't work. The compilation instructions fail.
Eternal Terminal: Remote terminal for the busy and impatient
11–20 of 73 posts
Re: Eternal Terminal: Remote terminal for the busy and impatient
#12After skimming the "How it Works" page, I'd be curious to know how they get around laggy interrupts, e.g. cat'ing a massive file and trying to Ctrl-C out of it. With Mosh, there's no giant delay because they don't care about history, they're just sending snapshots of the latest data. Hence why they use UDP as well.
ET however uses TCP, and some type of BackedReader and BackedWriter for TCP data - which _implies_ to me that everything is being sent/received in a massive queue. Also, it supports scrolling, which would be difficult _(but not impossible)_ if they only cared about recent frames like Mosh.
Finally, I'm curious how well it handles mobile connections. That's another selling point of Mosh. Admittedly I never use mobile internet, so that's not a concern of mine, personally.
I love Mosh and I'm always happy to see competing apps, hope they complement each other well :)
Re: Eternal Terminal: Remote terminal for the busy and impatient
#13Re: Eternal Terminal: Remote terminal for the busy and impatient
#14Can you outline briefly what the benefit of this is compared to mosh?
Its also Apache 2.0 licensed, compared to the GPL3 that strangles Mosh. Pity its not a freer license though.
How does a GPL license "strangle" a network connection tool? Are you really bothered that you can't incorporate it into your own BSD/closed source project, or is it a purely ideological "it's not BSD, so it doesn't respect me as a developer" stance?
Re: Eternal Terminal: Remote terminal for the busy and impatient
#15FWIW, I've had a lot of personal success with just plain SSH managing the resumption of sessions. The trick is to not send keepalives from the client, and to not time out idle sessions on the server. When you can control both of these, you don't need extra tooling to resume sessions.
That said, it's not as friendly to IP changes, nor does it provide predictive typing, so there's definitely something to be said for the value of tools such as these.
I do have one question, given the tmux and scrolling support, how much mosh-like lag compensation can ET provide?
Re: Eternal Terminal: Remote terminal for the busy and impatient
#16How robust is this to man-in-the-middle attacks?
Since it uses SSH to transport the initial session password, as robustly as SSH is.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#17How robust is this to man-in-the-middle attacks?
Since it uses SSH to transport the initial session password, as robustly as SSH is.
The initial password is only used for authentication, isn't it? Someone could (unless more details are provided) snoop on the connection or even inject packets.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#18Earlier quoted context omitted.
Since it uses SSH to transport the initial session password, as robustly as SSH is.
The initial password is only used for authentication, isn't it? Someone could (unless more details are provided) snoop on the connection or even inject packets.
[deleted]
Re: Eternal Terminal: Remote terminal for the busy and impatient
#19Can you outline briefly what the benefit of this is compared to mosh?
> benefit of this is compared to mosh?
I use byobu (screen) for all the things this is supposed to address. I think. Byobu doesn't keep your ssh connection from dropping but the session is still there once you reconnect with no loss of history. Plus you can connect from multiple clients (using the same user account).
Re: Eternal Terminal: Remote terminal for the busy and impatient
#20Earlier quoted context omitted.
Since it uses SSH to transport the initial session password, as robustly as SSH is.
The initial password is only used for authentication, isn't it? Someone could (unless more details are provided) snoop on the connection or even inject packets.
That was my concern too. So ssh is used for the initial handshake? BFHD. A lot of the interesting stuff happens afterward. The "how it works" page explicitly says this:
> ET does not implement any of the SSH protocol
That implies they rolled their own wire protocol. Maybe they did a good job (like mosh appears to have done). More likely not. I'd be OK using this on an internal network or over a VPN, but relying on it alone for security would be premature.