• Non-proprietary
• Federated
• Archivable
• Accessible
• Not dependent on a specific company
And having a built-in issue tracker
1. isn't related to those properties, and
2. isn't truly within the scope of a source code version control management solution.
That's the domain of project management.
It's rhetorical of course, it's because their users are completely blind to their pitfalls after decades of use, and it seems that generation-renewal is not a priority.
Discord servers and other contemporary solutions are much worse on the long run, but it does not matter. Software is like startups, long term is not a goal when you are not sure to survive (or in that case, being used and having contributors) next week.
As far as contributing go, coding a bug fix or a new features takes way longer than figuring how sending patch over mail works (for the extreme case) and you only need to do it once.
And opensource is not a popularity contest.
I don't think I've read anything that I disagree with so strongly in a while. "Software is like startups" is about as user and contributor-hostile a concept as they come.
The long term absolutely matters and projects choosing convenience today over long-term thinking are screwing over their future. It's damn near impossible to find information about these projects outside the proprietary silos they've dug themselves into and they will regret the choice one of these days when Discord or whatever proprietary service starts tightening the screws to make money.
I'm not sure what you find hostile about their web appearance. It's a light, clean page with text that doesn't throw tons of JS at you, pop-ups, or a cookie accept/reject/ponder bullshit dialog. It could use a bit of a copy edit / redo and a screenshot (I always complain when a project doesn't have screenshots...), but I don't find it hostile in the least.
I would be happy to engage on that thought, but here on this thread there is a lynchmob gathering to declare an emergency to remove all GPL-connected code everywhere, again.. because `screen`
Like any implementation, it comes with certain affordances which differ from other implementations.
Messages feel "heavy" for several reasons: sending one involves a lot of clicks (or keypresses); if you send a very high number you may be banned from your email provider, and unable to communicate with anyone.
Messages often arrive instantly, but can be delayed up to hours or days, so conversation round-trips are kept to a minimum.
Messages are all the same - there are no "lite messages" such as emoji reactions - so any message must contain enough content to justify being a full-fledged message, or it won't be sent at all. (Sometimes an "emoji reaction" is felt to be enough content to justify a full-fledged message, which is sent.)
Being off the web increases the barrier to entry, reducing the eternal september effect (ironically, Usenet is one of the least eternal-september-ish of the public discussion boards currently in existence).
Overall, the feel of the system tends to somewhat discourage quantity and encourage per-message quality.
Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?
It sounds like they requested the security review, but have been difficult to keep in touch with? I'm not sure what the whole story is there.
0: https://security.opensuse.org/2025/05/12/screen-security-issues.html#8-timelineIf that's the case, it's not really about it being "understaffed". Instead, it's doomed to rot until it's replaced of rewritten. There's no scenario where more maintainers will help, except for marginally delaying it.
The good news is that there are almost perfect replacements out there, and most of them are leaner.
https://git.savannah.gnu.org/cgit/screen.git/tree/src
A few 2kLOC files and the rest is rather small.
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.
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.
https://jdebp.uk/FGA/unix-login-database.html
The login accounting system that Linux-based operating systems have inherited from Unix really has never reconciled its initial real-terminal-login-only superuser-managed design with the fact that non-superuser programs that allocate pseudo-terminals (e.g. any local terminal emulator, NeoVIM, tmux, screen) want to (over)write entries for those pseudo-terminals in the login accounting database to make the output of the "who" command (and its ilk) more complete.
The best approach I've seen was to re-think the idea; have the pseudo-terminal-using programs run entirely unprivileged and use a client-server model where only the server actually has access to the database files.
Laurent Bercot did this. It fixes many holes, including that the log of log-ons/log-offs is made truly append-only (modulo superuser access to the underlying files). But it has the same architectural problem that any client in the group can overwrite any currently active login record if it knows the record ID, which by design (and the Single Unix Specification) there's an API for enumerating.
* https://skarnet.org/software/utmps/
Both the BSDs and M. Bercot have improved the situation with pututxline(), but it's still not out of the woods yet.
lrwxrwxrwx 1 root root 12 Feb 11 2022 /usr/bin/screen -> screen-4.9.0
-rwxr-xr-x 1 root root 455016 Feb 1 2022 /usr/bin/screen-4.9.0
no suid
I used to hate that Debian always was behind on software versions, but now I use different package sources for the few applications where I really don't want to rely on old software (like browsers), and otherwise doing great with the old stuff :-)
If you're running Firefox on Debian please make sure you manually update it since the package repo's been down for a while. I filed a 'support' ticket first ( https://support.mozilla.org/en-US/questions/1510388 ) since it seemed to be the proper place, but no one seems to look at those.
https://security.opensuse.org/2025/05/12/screen-security-iss...
http://www.zoobab.com/screenrc
GNU need a better issue tracking system :-)
Unix: Small, light, mediocre OS for underpowered microcomputers. Either crash silently, or cut down the bloat.
MIT/GNU: Correct systems first. Plenty or resources. Lisp. Detect the errors, fix and step over them, continue the process.
Now:
GNU=Ugly bloated umUnix like, mega light Elisp editor but s l o w and prone to lock. Good FS' on Linux. FDo it's mainly Red Hat bloatware. Screen does too much.
OpenBSD=Correctness, ISC licensed mainly. Unix bound, small tools, but so-so FFSv2. Sndio works. Audio, video and so on perms work, no DBUS needed. CWM it's really fast and much easier than I3. Dumb config, fvwm looks like rocket science. Tmux, no screen(1) except for ports. Snappy, easy to config and script. Use damn cu(1) for serial, thanks.
RMPR•3h ago
> Screen offers a multi-user mode which allows to attach to Screen sessions owned by other users in the system (given the proper credentials). These multi-user features are only available when Screen is installed with the setuid-root bit set. This configuration of Screen results in highly increased attack surface, because of the complex Screen code that runs with root privileges in this case
I wasn't aware of such a feature but I guess it's what makes stuff like tmate possible. Speaking of which, I wonder if tmux is affected by the same kind of vulnerability.
trollied•3h ago
qwertox•3h ago
trollied•2h ago
johnmaguire•33m ago
dooglius•3h ago
EDIT: Further down, TFA gives a plausible explanation: the current screen devs are not fully familiar with the code base. If so, the setuid-root approach was probably the easiest way to make the feature work in lieu of such familiarity.
JdeBP•3h ago
https://sources.vsta.org/comp.sources.unix/volume10/screen/
ngangaga•3h ago
90s_dev•3h ago
entropie•2h ago
noosphr•1h ago
Tmux's main use case is to be glue for a unix IDE.
The two use cases are rather different and the tools are very specialized for them.
skydhash•1h ago
kps•1h ago
anthk•1h ago
noosphr•1h ago
taeric•27m ago
kstrauser•14m ago
penguin_booze•1h ago
Not an emacs user, but for this, what does screen do that tmux can't?
kstrauser•16m ago
johnmaguire•34m ago
jstanley•16m ago
DrillShopper•1h ago
SSLy•1h ago
Cerium•13m ago
dbdoskey•26m ago
lxgr•23m ago
Or is it more of a fish vs. zsh type of situation, where neither is obsolete, but the target audience is just very different?
kstrauser•17m ago
eblume•11m ago
tmux, to me, feels like "modern screen". It has some cool features, but at the end of the day, it just wants to be a terminal multiplexer. Great!
Zellij on the other hand seems to offer terminal multiplexing as an obvious first-class use case but "not the whole point". At the surface, Zellij is an opinionated terminal multiplexer that uses a nice TUI to give discoverability which you can turn off when you're ready to gain screen real estate. It's easy to make Zellij behave exactly like tmux/screen, and it's easy to configure via a single config file.
Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things. For instance I once built[0] a python cli app which had a command that would launch a zellij workspace with various tabs plugged in to other entrypoints of that same python cli, basically allowing me to develop a multi-pane TUI as a single python Typer app. In one pane I had the main ui, and then in another stacked pane I had some diagnostic info as well as a chat session with an llm that can do tool-calling back out to the python cli again to update the session's state.
I think wrapping up a project's dev environment as a combination of mise (mise.jdx.dev) and zellij or nix+zellij to quickly onboard devs to, say, a containerized development environment, seems like a really neat idea.
0: https://github.com/eblume/mole/blob/main/src/mole/zonein.py -- but this is mostly derelict code now, I've moved on and don't use zellij much currently.
guappa•1h ago
rixed•12m ago
JdeBP•1h ago
* The original author of the project has not been involved in it since 1990. The people who took it over and made it a GNU project then largely stopped working on it in 2004. The people who are now working on it are something like its 3rd or 4th wave of developers.
* Learning the internals of screen now from scratch is a lot harder than when I did it in 1987. There's an awful lot more operating system historical and portability factors, now. In 1987, it was works-on-4.3BSD-might-not-on-your-Unix.
* If you deal with pseudo-terminals cross-platform, there are still huge variations on how pseudo-terminals work and how the long-standing security issues of pseudo-terminals, identified in the 1990s, have been addressed in operating systems.
* screen is encumbered by a lot of 1980s Think. It still today diligently manages, and puts quite a lot of effort into constructing, a generated-on-the-fly TERMCAP environment variable, for example.
* Attitudes to security have changed. At least one security hole in the headlined report was actually a neat-o feature of terminals in Unix in the 1970s and 1980s.
okbitbuddy•1h ago
As pointed out the code is old. What it relies on is old, well known. Grep and awk with these well known concepts will shine light on concepts used.
This is not hard work. Developers have optimized for laziness as their biology lives the experience of sitting idle. No decoupling the performance of devs from the routine state of their being. Sedentary analysis has created a bunch of sedentary people.
JdeBP•48m ago
It's very hard work, especially nowadays. The sweet spot was probably in the 1990s, when novices were still likely to know that prime sources of knowledge about this stuff were posts on Usenet, or shell archives of text files written by Daniel J. Bernstein.
https://jdebp.uk/FGA/bernstein-on-ttys/
I speak from experience of being someone who did my own tweaks to screen in the 1980s, and who has written other similar programs from scratch.
cedilla•17m ago
Really, the gall to complain about "laziness" when all you're doing is spreading negativity on a forum.
bulatb•1h ago
fullstop•2h ago
fzzzy•2h ago
chasil•1h ago
CVE-2025-46802 can impact earlier releases, but all the other vulnerabilities are for the latest.
thanatos519•32m ago
Not surprised to hear it's full of security holes. :)