Eternal Terminal: Remote terminal for the busy and impatient
21–30 of 73 posts
Re: Eternal Terminal: Remote terminal for the busy and impatient
#22Why does it need it's own port if it rides over SSH? Couldn't SSH just forward a port?
Re: Eternal Terminal: Remote terminal for the busy and impatient
#23So it is mosh, but much better? I'll try it.
The PPA doesn't work. The compilation instructions fail.
What problems are you encountering? It might be worth opening a GitHub issue.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#24Earlier quoted context omitted.
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
#25Earlier quoted context omitted.
The PPA doesn't work. The compilation instructions fail.
Compilation works for me: https://asciinema.org/a/LkPYDdWkGgFybny8ChqOLQA8e What problems are you encountering? It might be worth opening a GitHub issue.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#26Earlier quoted context omitted.
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?
It's a pain to get mosh support in iOS clients, yeah.
https://github.com/mobile-shell/mosh/blob/master/COPYING.iOS
It's a pain to get mosh support in closed-source iOS apps, but I think that's a good thing, and that's more about the closed-source requirement. (Though the iOS requirement means that you can't take the fork-and-exec approach that e.g. JuiceSSH on Android does; your whole app has to be free software.)
There's a free-software one that charges money on the App Store for a precompiled binary, which seems like the right plan: https://github.com/blinksh/blink
Re: Eternal Terminal: Remote terminal for the busy and impatient
#27Earlier quoted context omitted.
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…
--Edit--
A quick glance at the repo suggests they're using NaCl to handle the encryption + the SSH server for auth
Re: Eternal Terminal: Remote terminal for the busy and impatient
#28Earlier quoted context omitted.
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?
It's a pain to get mosh support in iOS clients, yeah.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#29After 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 m…
Presumably with the TCP URG flag. That said, I only read years ago that's how it's done, without ever checking myself. I've found references to in in telnet, but not ssh, so perhaps the latter uses some other mechanism.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#30FWIW, 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 th…