Hacker News new | ask | show | jobs
by acqq 2867 days ago
I understand this as a "compatibility with * nix" existing software, not as an "amazing feature." Can anybody suggest why I should like it, except for the compatibility with the software written for * nix terminals? Even ssh being too interconnected with a terminal down to the many details was a shock for me... I expected the simple encryption mechanism, over which whatever communicates, even if that would implement the "sh" part of it only on top of that, but no, it's everything spaghettisized and recombined with everything unnecessary like emulating the devices that don't exist for many decades -- in something that should have a clear separation between the task of transporting encrypted data with authenticating from anything else. I can't see it as being positive, security-wise.

Isn't it strange that today everybody has very powerful GPUs and CPUs and the graphical displays with immense RAM and then using all that to emulate the terminals last existing decades ago appears to be so important, even for something that should be just a secure communication protocol?

Why do we still spend so much energy to decide which console of many decades ago we "support" when it seems that all are flawed, at least compared to what the modern OSes can provide, as soon as the "compatibility" is not needed?

Isn't all that "hardware console" compatibility stuff just a historical accident from the "bad old days" of 300 baud lines between the mainframe and the "terminal" which had a few bytes of RAM total? In the days when e.g. the Thunderbolt 3 can carry 5 GB/s, and the rest of the hardware matches? Why do people still so cling to it? I'd really like to know what I am missing.

1 comments

> I expected the simple encryption mechanism, over which whatever communicates

In the UNIX world, that's what it gives you - a stream of bytes. Hence things like rsync-over-ssh or git-over-ssh. It also has a port forwarding mode which has special support for X11, which gives you remote windowing over a stream of bytes too.

The main, huge, benefit is that the abstraction is pretty simple, it's discoverable, and you can use the same interface as a human. You can also plug any stream-of-bytes into any other stream-of-bytes, whereas API or RPC based systems have to be designed to interoperate.

As I’ve tried to implement my minimal ssh client (just to connect, execute some command and get the result) I’ve had exactly opposite impression of the “just a stream of bytes” that you mention -- exactly the lack the abstraction. Can you point to any source that does ssh without having to care about a lot of weird terminal and console ancient stuff? I’d be really glad to see it! To me it looked as “everything and the kitchen sink” (that is, exactly the kind of things mentioned in the OP or the comments, like terminal signals and whatnot) has to be there.

SSL is straightforward compared that, at least, once the keys are set. But ssh... as seen in the OP even the console or the terminal or however that part it called has to be very special, and they are obviously proud they implemented that too. In 2018. Probably decades after the last single hardware terminal was sold.

I see your point - but don't you find it kinda charming? It's a bit like drinking tea in a china cup, or eating a scone with clotted cream.

I think there is probably a lot of room for improvement in the terminal world, and I agree that a lot of the really old stuff makes things a bit counter-intuitive, but for whatever reason, it seems that people who make really good software also tend to be the people who are pretty fanatical about backwards compatibility. Consider vim, for instance.

In the end, I think the basic model of interoperable, small programs that manipulate streams of text is really good - so people will put up with any number of weird rituals to live in that model. It's also very humble, and very unexciting, so it's the kind of thing that's hard to get people hyped about. So it probably filters by the people that like old things.

You are conflating what SSH does with what the terminal you're running it in does. SSH barely knows what terminal emulation is. You can literally pipe binary data into it at one end and receive that data into a program at the other end. That's what programs like scp and rsync do. They launch ssh and use it as a data channel.
> You can literally pipe binary data into it at one end and receive that data into a program at the other end

That is the user perspective, not what has to be in a ssh program to work.