Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

Isn't this what distros are for? So e.g. Debian could decide to replace screen with tmux, possibly with some sort of compatibility package that takes all the same command line arguments as screen but uses tmux under the hood. (I've used screen very little and have never used tmux so I'm not sure if that would make sense in this context).

View on HN

You generally can’t transparently replace a tool by a different one like that, siblings are giving examples of where there would be incompatibilities. There would also be much upheaval among users if a distribution would try to underhandedly perform such a replacement. If anything, a package “tmux-as-screen” could be provided for those who want that.

> If anything, a package “tmux-as-screen” could be provided for those who want that.

To be clear, that's what I was imagining. If you had a shell script that called screen, it would now work via tmux, but no one would be "tricked".

In that case, nobody would be tricked because they would have to explicitly select that package. Those already having screen installed, or selecting screen for installation, wouldn’t automatically be upgraded to tmux-as-screen. So what the comment you replied to mentioned as a problem of inertia and there being “no immediate incentive to switch” would remain largely unaddressed.

Well, I guess the other part would be removing screen from the official repo. So the original utility is gone, but we have a compatibility package you can install that should make things work like they used to. (Of course, if you really still want screen you can build from source or some such.)

Tmux doesn't support serial ports.

I'm not sure what made "screen" integrate the two separate pieces of functionality - you can use something minimal like "tio" for serial port access and it's much more elegant.

It isn't separate functionality. Terminals connected via serial port is a valid use case for a terminal multiplexor.

In theory you're correct, but by that logic you'd also have to add ssh (probably by far the most common way of connecting to a remote terminal today). I guess you'd end up with something like mobaXTerm which is a valid approach for sure, but doesn't compose as well.

Personally I live by the maxim "if it can be separated without significant drawbacks, then it should be separate" but GNU tends to see it differently.

I dont think you understand what a terminal is. What you’re talking about is a shell running in a console. What we’re talking about is the terminal to connect to the console serial port running the shell.

EG https://en.m.wikipedia.org/wiki/VT220

It's not separate functionality. The back end (so-called "master" side) of a pseudo-terminal is almost (bar initialization of line speed, hardware flow control, and framing settings) indistinguishable from a "null-modem" call-out serial port or parallel port terminal device. Write a software terminal emulation program for the former, which of course is what screen has, and you already have one for the latter.

I'm sure a rewrite of screen in Rust will be 105% secure. And won't support serial ports either.

What is a serial port and what do you use it for?

It is a port that has two data lines, RX and TX, and data is sent in a serial fashion across those data lines. It is used today for embedded systems, routers and switches et al, and getting a console on any machine that doesn't have a gpu with a monitor attached.

USB is a serial BUS, which allows multiple devices; serial ports are single device (if my memory serves).

When most people use the term "serial port" they're referring to a DB-25 or DE-9 port you find on older computers or USB dongles. It's also seen in 8P8C (aka "RJ45") form sometimes, especially in industrial equipment. It can send and receive "characters" (anywhere from 5-8 bits each) one at a time at a fixed rate, either half duplex or full duplex. They usually implement one or more of the RS232, RS422, or RS485 standards.

Originally, you communicated with the computer using a teletype or video terminal connected to a serial port. Whatever you typed went to the computer, and whatever the computer sent back was printed on your terminal screen (or paper in the case of a teletype).

The UNIX (and thus, Linux) command line environment still works this way, except the serial line is virtual.

console=ttyS0,115200

Just use minicom

A smooth transition from GNU screen to tmux, will be appreciated for potentially 60K users.

https://qa.debian.org/popcon.php?package=screen

I note that tmux has only 40K users (of debian popcon users)

https://qa.debian.org/popcon.php?package=tmux

I am considering to try the link shared previously:

https://github.com/grml/grml-etc-core/blob/master/etc/tmux.c...

Now I miss a way to translate CLI options and batch files

You can reconfigure the key-bindings, that I guess would be the largest annoyance for a new user. But there are many fundamental differences between them that you just can't hide.

Reply on news.ycombinator.com