Live data from Hacker News

Eternal Terminal: Remote terminal for the busy and impatient

mistertea.github.io

21–30 of 73 posts

Re: Eternal Terminal: Remote terminal for the busy and impatient

#22
post #21

Why does it need it's own port if it rides over SSH? Couldn't SSH just forward a port?

It could, but then it would have to deal with the SSH line protocol which is complicated, because it allows for a LOT of stuff. ET is basically pretty dumb, it basically just dumps a PTY onto the network, and is way simpler.

Re: Eternal Terminal: Remote terminal for the busy and impatient

#23
post #11
post #9

So it is mosh, but much better? I'll try it.

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

#24
post #10

Earlier 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?

It's a pain to get mosh support in iOS clients, yeah.

Re: Eternal Terminal: Remote terminal for the busy and impatient

#25
post #11

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

It is not clear from the error that you were missing libsodium. I don't remember what was my error anyway, I'll try again later. But I can't even find libsodium on my apt.

Re: Eternal Terminal: Remote terminal for the busy and impatient

#26
post #24

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

Even with the explicit waiver of anything in the GPLv3 that might possibly conflict with iOS App Store requirements?

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

#27
post #17

Earlier 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…

I think that sentence implies they're using OpenSSH not that they're rolling their own?

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

#28
post #24

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

Sounds to me like it's rather iOS's restrictive licencing rules that are strangling itself.

Re: Eternal Terminal: Remote terminal for the busy and impatient

#29

After 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…

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

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

#30

FWIW, 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…

I'm curious. What's the ssh options for managing the resumption of sessions?
Post reply on HN