Multiple security issues in GNU Screen

Open source does have a problem with inertia whenever one piece of software ends and another piece is created to replace it, but there's no immediate incentive to switch, because it is a switch, not an update.

Though conversely, when someone buys the trademark for an existing piece of software, and replaces it with something entirely different, like what happened with Audacity, that's also bad. So there's no good solution.

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

Tmux doesn't support serial ports.

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.

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.

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

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

The good solution is rock-solid, backwards compatible APIs on all levels. That way the work to maintain software would be much lower, making it possible to focus on doing some rare bug-fixing only. In open source in particular this should be a no-brainier, instead of all projects ruining things for each other by ignoring backwards compatibility.

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.

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.

The rock-solid backwards-compatible API would include, for example, being invoked with the command "screen -x", and being installed with "apt install screen" - at which point it's the same screen project under different management, not a new project.

> Though conversely, when someone buys the trademark for an existing piece of software, and replaces it with something entirely different, like what happened with Audacity, that's also bad. So there's no good solution.

I've followed the Audacity situation over the last few years. Before the Muse Group bought the rights to the trademarks and took over development, Audacity development had pretty much stagnated.

The new developers did not replace it with something entirely different. What they did was fix longstanding bugs and add new features/enhancements (and changing the way some things work, for better or worse). Sure, they introduced new bugs here and there with the new features/enhancements, but last I checked they fixed those. And yes, they could have done a better job at marking new versions as "beta" rather than pushing them out as stable releases (old hands know to avoid a new version until a couple minor versions later). That's really my biggest gripe with their development/release process.

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

I was referring to the APIs required by screen itself to run. If screen is anything like any software I know anything about a fair amount of limited developer time has to be wasted on keeping up with random third-party stuff changing/breaking. Even if that is not the case, if we get more stable software in general that would mean maintainers of free software could take on more projects each, meaning there would be a higher probability that someone could be around to fix bugs in screen.

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

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

They are completely redesigning the UI to such an extent that it may as well be a completely new project.

Also, how come open source names can even be bought? They should be open, of course, so I think it'd be fair enough if they wanted to call theirs "MuseScore Audacity" or something like that.

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.

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

console=ttyS0,115200

Just use minicom

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