> 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.
dooglius 9 hours ago [-]
No, tmux uses unix domain sockets. I have no idea why screen chose to take the setuid approach instead here; it seems totally unnecessary to have root privileges.
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 9 hours ago [-]
screen has a lot of architectural baggage that can be traced back to its initial 1987 comp.sources.unix/mod.sources versions in some cases. Being set-UID to the superuser is one of them. See the doco for screen as it was posted in volume 10:
Kind of nuts that a tool that hasn't fixed nearly 40-year old practices is in common usage among developers. Never tell me engineers are rational people.
JdeBP 7 hours ago [-]
It's a combination of factors:
* 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 7 hours ago [-]
[flagged]
JdeBP 6 hours ago [-]
Port something like this to OpenBSD and then say that this sort of thing is not hard work. (-:
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.
If I recall correctly (I transcribed that years ago.) they were lost in the original. They wouldn't have been links. It was written in 1991.
6 hours ago [-]
okbitbuddy 6 hours ago [-]
[flagged]
cedilla 6 hours ago [-]
What's your point besides whining about the general state of "delevopers", whoever that is? Are you volunteering to take over maintenance of GNU Screen?
Really, the gall to complain about "laziness" when all you're doing is spreading negativity on a forum.
okbitbuddy 6 hours ago [-]
[flagged]
okbitbuddy 6 hours ago [-]
[flagged]
entropie 8 hours ago [-]
For me it felt (!) like screen is pretty much obsolute since 10+ years. When tmux came I switched and never looked back and I know a few that handled it the same.
DrillShopper 7 hours ago [-]
Try as I might I cannot get my fingers to re-learn the tmux keybindings. The GNU Screen keybindings are that burned into my brain.
cheema33 1 hours ago [-]
> Try as I might I cannot get my fingers to re-learn the tmux keybindings. The GNU Screen keybindings are that burned into my brain.
This. I have tried switching away from screen a few times. But failed because the keybindings are burned into my brain as well.
Thankfully you can configure it. I had the same initial difficulty.
imoverclocked 3 hours ago [-]
That’s great for your own machine or even common home directory scenarios. The issue is when you have a bunch of machines to manage without chef/puppet/etc or hop onto a random machine or a machine you don’t own etc… defaults are what you get to work with.
If screen is there and I need to do something that lasts longer than my ssh session, screen is what I reach for. If it’s non-interactive, I reach for nohup next.
dbdoskey 6 hours ago [-]
A similar process is happening with zellij and tmux. Since I switched over I feel that tmux is obsolete.
fullstop 6 hours ago [-]
I hadn't used Zellij before, but I tried it out. Visually it works better than tmux and it shares enough key bindings with tmux to make it a pretty seamless transition.
With that being said, the binary is huge. I get that zellij is statically linked, but tmux is about 900KiB and has minimal dependencies. I'm flabbergasted that a terminal multiplexer, stripped, is 38MiB.
kstrauser 4 hours ago [-]
True, but zellij also does more. I'd also give it more of a stink eye if it were something I were running many times inside the inner loop of a script, but as something you generally launch once and leave running forever, eh.
I occasionally have to recalibrate my units. I just launched Emacs on my Mac and it's using 350MB of RAM. That's astonishing when I think about Amiga programs I wrote, but it's also just 0.53% of the RAM in this particularly machine. It's probably larger than it could be if someone ruthlessly trimmed it back, but I'd rather spend that time using the other 99.4% of my machine to do more fun stuff.
fullstop 2 hours ago [-]
I have a few embedded devices which have just 128MiB of flash, and they can run tmux just fine. I wouldn't even consider zellij for this purpose, of course, and having tmux down there is more of a "this is a nice thing for development purposes" thing.
Regarding memory usage, Zellij appears to take up 63 MiB versus tmux's 3.8MiB. It's nice and all, but quite a pig. This is on Linux, maybe Mac is different.
kstrauser 2 hours ago [-]
Embedded is a lot different, to be sure. I'm surprised there's room for tmux on something that tiny.
But on desktop systems, on my Mac, Zellij takes 28MB of disk and 40MB of RAM. That's 1/37,000th of my available disk and 1/1,600th of my RAM. I'm all for optimized, tiny apps, but those are below my attention threshold.
int_19h 51 minutes ago [-]
Note that "embedded" like this includes e.g. many modern routers.
Also note that computers with much less disk space than 128 Mb could and did run full-fledged GUI apps in the past. For example, the entirety of Windows 95 is ~100 Mb when installed.
fullstop 37 minutes ago [-]
The product uses libevent and libc already, so adding tmux only consumes a few hundred KiB in the image. The root filesystem is squashfs, so it's even less in practice.
spookie 4 hours ago [-]
Looking at the source code I assume it's just the amount of cargo deps. Some of which I'm not sure what place they have on a tmux at a first glance.
fullstop 2 hours ago [-]
Hopefully some effort is eventually put into slimming things down.
lxgr 6 hours ago [-]
What does it do better than tmux?
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 6 hours ago [-]
A quick example is that mouse scrolling works by default. I see it more like ripgrep vs grep. Either can do almost anything the other can, but one has much more modern, ergonomic defaults.
eblume 6 hours ago [-]
Definitely more of a fish vs zsh situation, in my opinion.
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.
> 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.
That’s been a pretty standard feature of tmux since forever.
In fact the reason I first discovered tmux was because some Irssi (terminal IRC client) plugins used tmux to create additional panes for Irssi.
tmux is one of those tools that does a lot more than most people realise but the learning curve is steep and features aren’t easy to discover.
Zellij looks interesting but these days I mostly use tmux as a control plane rather than a terminal UI. So the enhancements of Zellij are wasted on me.
thesuitonym 2 hours ago [-]
Among a certain subset of linux users, new is always better.
psychoslave 4 hours ago [-]
I used to used zsh, like I still have have karma moving up on stackoverflow as I answered my own questions on some obscure configuration fine tuning. But currently I'm more in a "give me the thing that work off the shelf" moment, so I take fish and don't plan to either look back.
Byobu with tmux as backend is my go to solution if I want a multiplexer, for what it worths.
How though? Genuine question; x11 didn't obsolete terminals. Does Arcan do something X11 couldn't?
skydhash 4 hours ago [-]
From a quick read, all I can see is a manifesto for emacs.
noosphr 8 hours ago [-]
Screens main use case is to open an emacs session remotely.
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.
jstanley 6 hours ago [-]
Nah, screen's main use case is as an ad-hoc method to daemonise random scripts.
fnordpiglet 5 hours ago [-]
Yeah this is 100% of when I reach for screen. “I’m not willing/ready to make this a service, screen detach here I come”
skydhash 7 hours ago [-]
I switched to dtach for the first case.
kps 7 hours ago [-]
dtach for session persistence. “Do one thing well.”
penguin_booze 7 hours ago [-]
> Screens main use case is to open an emacs session remotely.
Not an emacs user, but for this, what does screen do that tmux can't?
wkat4242 2 hours ago [-]
Nothing but replacing it with something newer invalidates decades of muscle memory.
I switched to tmux eventually though.
kstrauser 6 hours ago [-]
Nothing at all. I’ve used emacs over tmux (and now zellij) for many years. Emacsserver can replace both of them, but that’s a different story.
johnmaguire 6 hours ago [-]
I'm confused by this statement. Are you claiming this is the projects' stated goal? Their primary use in the wild?
anthk 7 hours ago [-]
Emacs can work as a daemon.
noosphr 7 hours ago [-]
It also has tramp mode which means you can use all your local packages remotely.
taeric 6 hours ago [-]
When I realized how powerful TRAMP was, I don't think I ever used screen/tmux again. I'm sure there are uses, mind. Just TRAMP fully hit all of my needs.
kstrauser 6 hours ago [-]
It really is magical, isn’t it? And although I rarely need to use it, I love the multihop setups where you can ssh to this system, then ssh again to this other, then mount an SMB filesystem using these credentials, and start editing.
guappa 8 hours ago [-]
On my sistems screen doesn't have setuid.
bombcar 4 hours ago [-]
On my gentoo box it's setgid hmmm.
Ubuntu it's not set.
rixed 6 hours ago [-]
Same here (speaking more specifically about debian)
90s_dev 9 hours ago [-]
Nostalgia and novelty are powerful narcotics.
1vuio0pswjnm7 5 hours ago [-]
Engineers are rational people. Software developers calling themselves "engineers" are not.
wkat4242 2 hours ago [-]
True, it's not really as if it's a massive codebase
7 hours ago [-]
mardifoufs 4 hours ago [-]
Is it actually in common usage? I'm sure it's used by a lot of people, but it seems quite niche still.
wkat4242 2 hours ago [-]
It's used a lot for legacy reasons I think. People didn't move to something newer like tmux because why would they? It's super handy to keep stuff running on a console while disconnected from it. In that sense it (or at least, tools like it) are indispensable.
UI_at_80x24 5 hours ago [-]
We usually wait for a version written in Rust for this kind of cruft removal.
nine_k 5 hours ago [-]
The problems here are more about the architecture. You can write 100% memory-safe but completely insecure code in Rust, Java. Haskell, Erlang, Smalltalk, bash, you name it. For instance, running a setuid binary may add problems to code written in any language.
3 hours ago [-]
chasil 7 hours ago [-]
In the EPEL versions of screen, I am seeing the setgid bit set only. I am guessing that later versions setuid to root?
CVE-2025-46802 can impact earlier releases, but all the other vulnerabilities are for the latest.
fzzzy 8 hours ago [-]
screen has used setuid root for multiuser for at least 20 years. Used to use it in multiuser for remote pair programming.
icedchai 1 hours ago [-]
I remember installing screen on a SunOS box back in the early 90's. It's been around a longggg time.
fullstop 8 hours ago [-]
I guess I'm glad that I switched to tmux ages ago.
thanatos519 6 hours ago [-]
It's a great feature! I have used it in training sessions by giving each student their own login on my laptop, with the ssh shell restricted to 'screen -x <specific user's window>' - the only window that user could use based on screen's ACLs. Then during exercises I (as the owner of the screen) could switch to each student's screen on the projector so the class could see what they had done.
Not surprised to hear it's full of security holes. :)
trollied 9 hours ago [-]
Yup, screen -x
qwertox 9 hours ago [-]
The problem isn't with the use of `screen -x ...` itself, but rather if `ls -l "$(which screen)"` returns something like `-rwsr-xr-x 1 root root ... /usr/bin/screen`, where the `s` in the fourth position indicates the setuid bit is set.
That means the screen binary runs with root privileges.
trollied 8 hours ago [-]
I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
johnmaguire 6 hours ago [-]
I was surprised to hear OP wasn't aware of it as it was the first reason I ever had to use screen (shared remote debugging session.)
1 hours ago [-]
teddyh 9 hours ago [-]
Note: In Debian, GNU screen is not installed with setuid-root privileges.
perlgeek 8 hours ago [-]
And the package in Debian Stable (aka bookworm) is too old to be affected by the vulnerabilities in 5.0.0.
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.
foresto 5 hours ago [-]
This is about Mozilla's builds of Firefox for Debian, not Debian's builds, right? So regular Debian users who run the default Firefox (firefox-esr) would be unaffected.
mjevans 4 hours ago [-]
Correct, but that's firefox-esr not firefox. At one point I found it necessary to switch as there was an issue with security updates, but that might have been an issue in that particular system's configuration that I since resolved.
sillystuff 5 hours ago [-]
The repo appears to be working for installing/updating packages. Mozilla should allow file listing which should fix the 404s, and make this repo behave as expected when manually browsed (Apparently hosted on a Google webserver; maybe Google forbids this?).
apt-get changelog firefox
Get:1 store: firefox 138.0.3~build1 Changelog
Fetched 129 B in 0s (0 B/s)
firefox (138.0.3~build1) UNRELEASED; urgency=medium
* N/A
-- Mozilla <release@mozilla.com> Mon, 12 May 2025 12:40:33 -0000
date
Tue May 13 08:56:09 AM PDT 2025
Or, to really prove it to yourself, you can re-download the package:
I will have to look into that more tomorrow. My only Debian desktop is a laptop at family's house and currently asleep. It mentioned an error with the repository but my first troubleshooting step was to try to manually verify I could _get_ to the repo in a browser.
jesprenj 9 hours ago [-]
Likewise in Gentoo. But in Gentoo it has SETGID for utmp group. Though I'm not sure what the implications are.
JdeBP 8 hours ago [-]
If one is in group utmp, one can mess with the login accounting database: the table of currently active logins, the log of log-ons/log-offs, and the table of per-user last logins.
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.
Tmux has been in OBSD base side several releases and documented since the first one.
CelestialMystic 7 hours ago [-]
I know. I suggest you read the Q&A I posted.
2 hours ago [-]
kazinator 1 hours ago [-]
Funny you should mention screen and setuid. In one installation, I had to give screen chmod u+s perms to solve some weird issue, thinking what a gross thing to do.
Turns out, it has features dependent on setuid, and some systems ship it that way? Yikes!
(But, after I gave u+s to screen, it reads root's ~/.screenrc instead of mine (which I accepted as part of the workaround). Maybe that particular build of screen I'm using doesn't react properly to setuid; maybe it has to be built a certain way also to enable that support.)
mmsc 9 hours ago [-]
It's surprising that upstream was involved in this. Around 5 years ago, I came to the (sad) conclusion that GNU screen development had completely halted. Is that still not the case?
Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?
jzb 8 hours ago [-]
Upstream requested that the SUSE team take a look at it. It seems that development is understaffed and the upstream may not have the expertise to maintain it properly. Which, if true, is sad -- I know that tmux and others exist, but a lot of people have used Screen for many many years. It sucks when a tool bitrots.
marcosdumay 7 hours ago [-]
Looks like a tech-debt ridden large piece of software that new developers just can't understand.
If 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.
narag 4 hours ago [-]
Instead, it's doomed to rot until it's replaced of rewritten.
I've seen how that mindset has ruined several companies. Not saying that you're wrong about that particular program that is, after all, free software replaced by other free software parts. But for business, it's lethal.
What are the replacement tools I should be looking at as a casual user of screen?
kstrauser 4 hours ago [-]
If you want screen-but-better: tmux.
If you want a rethinking of the idea: zellij.
I prefer the latter. It matches my mental model of such things, and lots of people talk about enjoying switching to it. Many others happily use the former daily.
bombcar 3 hours ago [-]
tmux is great but it's way too powerful for the 90% use case of screen - which is "let this process continue to run even if I disconnect or logout".
I've had some luck with mosh, but that also seems kind of moribund.
Involved only insofar as shipping it as setuid-root counts. Distros that configure it like this are vulnerable, others aren't. Very thin involvement I'd say. Distros patch if upstream is too slow.
mmsc 9 hours ago [-]
TFA says upstream asked for the review.
croemer 7 hours ago [-]
Right, I got the direction wrong.
Eduard 4 hours ago [-]
"TFA"?
shawn_w 4 hours ago [-]
The Fine Article
criddell 7 hours ago [-]
It’s not necessarily sad for GNU tool development to stop (other than bug fixes, of course). I would take that as a sign that they are basically complete.
kstrauser 6 hours ago [-]
Not quite in this case. Tmux was started by someone who wanted to update screen with new features but wasn’t able to bend the code that far. I say this not out of spite or meanness, as I used screen for many happy years, but I’d say it’s less complete and more abandoned. It still has maintainers but it seems to me that they’re more “keep the lights on” than actively developing it.
Kwpolska 2 hours ago [-]
It's not sad if a good Stallman-free alternative exists. Like tmux.
lxgr 6 hours ago [-]
Whether constant development is necessary or not largely depends on the surface area of your tool, both in terms of formal APIs it uses and external data formats and services.
dundarious 4 hours ago [-]
screen didn't even have vertical splits until maybe 5 or 10 years ago. After tmux was already a solidly reliable replacement with vertical splits for years.
wkat4242 2 hours ago [-]
True, this is why I switched to tmux.
Trasmatta 9 hours ago [-]
> Due to difficulties in the
communication with upstream we do not currently have detailed
information about bugfixes and releases published on their end.
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.
mmsc 9 hours ago [-]
Seems like a prime target for Jia Tan.
tecleandor 9 hours ago [-]
Yep, from the timeline it looks like lack of communication (and maybe also capabilities/resources/time/will, not sure) [0]
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.
unixplumber 5 hours ago [-]
> 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.
immibis 3 hours ago [-]
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.
3036e4 7 hours ago [-]
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.
immibis 6 hours ago [-]
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.
3036e4 5 hours ago [-]
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.
Wowfunhappy 8 hours ago [-]
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).
rzr 5 hours ago [-]
A smooth transition from GNU screen to tmux, will be appreciated for potentially 60K users.
Now I miss a way to translate CLI options and batch files
layer8 4 hours ago [-]
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.
marcosdumay 7 hours ago [-]
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.
kevin_thibedeau 7 hours ago [-]
Tmux doesn't support serial ports.
PhilipRoman 7 hours ago [-]
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.
JdeBP 6 hours ago [-]
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.
kevin_thibedeau 7 hours ago [-]
It isn't separate functionality. Terminals connected via serial port is a valid use case for a terminal multiplexor.
PhilipRoman 6 hours ago [-]
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.
im3w1l 5 hours ago [-]
What is a serial port and what do you use it for?
spauldo 2 hours ago [-]
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.
genewitch 5 hours ago [-]
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).
nottorp 7 hours ago [-]
I'm sure a rewrite of screen in Rust will be 105% secure. And won't support serial ports either.
1. How many developers run all the most popular open source tools?
2. How much money is in the industries that use those tools?
seethishat 6 hours ago [-]
tmux is in OpenBSD base since 4.6 IIRC and is/has been audited. It's a good alternative for those who want something a bit more secure.
j45 6 hours ago [-]
Seeing screen popup reminded me of that one time I switched to tmux and forgot to use screen.
sundarurfriend 6 hours ago [-]
Zellij is a really nice, modern alternative to screen and tmux, and they've done a great job at having good defaults as well as making the UI easily discoverable. I'd highly recommend it to anyone else who felt dubious about the benefit-to-effort ratio of terminal multiplexers.
I gave it a shot a couple years ago -- pretty slick. But the latency was noticeable compared to tmux, which I remain using today. I admit that I'm kind of sensitive to it, as at the time I was already on a latent connection.
kstrauser 4 hours ago [-]
I personally haven't noticed that, but we all have different sensitivity levels to such things. Have you tried it more recently? A couple years ago is ancient in its lifespan. I'd be curious to see if it still feels sluggish to you.
(Not a dev, just another end user.)
collinvandyck76 4 hours ago [-]
No, haven't tried recently, but will make a note to do so. Agree that a couple of years is an eternity :)
kstrauser 2 hours ago [-]
Right on. I'd love to hear back about that.
It could also be in my case that I use it so little that some latency is tolerable. I don't develop interactively in zellij or tmux. I mainly keep some logs tailing, and DB consoles open, etc, and I don't check them super often.
Scene_Cast2 7 hours ago [-]
I use byobu (for the keybinds) on top of tmux. But Zellij (modern Rust-based alternative to tmux) has been looking quite interesting for a while.
indigodaddy 3 hours ago [-]
Are there any official RedHat CVE pages for any of these screen vulns yet? Haven't found anything so far
fistikcisahap 54 minutes ago [-]
RedHat removed screen from the distro repos starting from RHEL8 and recommended tmux as the replacement.
It's still in EPEL I think but I guess that releases RH from having to address it?
warpeggio 9 hours ago [-]
So ... my tmux lifestyle is objectively superior in this one respect. Excellent.
exploderate 8 hours ago [-]
Yes, that's why all the cool kids switched to tmux 17 years ago. The only argument the screen camp had was "no serial port support in tmux". To which we answered something about a smaller more modern code base...
remram 6 hours ago [-]
I switched to tmux and I switched back due to the weird server/session/window/pane model that makes no sense and prevents me from showing different windows or layouts on different clients. 4 levels of objects is ridiculous and when you end up with less capabilities than screen, what are we doing?
I would love to switch to a modern, maintained terminal multiplexer, but it would need to, well, be good at multiplexing.
kstrauser 6 hours ago [-]
I haven’t done serial port stuff in many years, so I ask this in ignorance and I give you permission to laugh at my naïveté. Can’t you just run tip or something in a tmux or zellij window and have basically the same thing?
pengaru 6 hours ago [-]
> The only argument the screen camp had was "no serial port support in tmux".
No, the screen camp has the valid argument that licenses matter and tmux is not GPL software.
int_19h 17 minutes ago [-]
From the end user perspective, it makes zero sense to avoid software just because it has an open source license that is more liberal than GPL.
charcircuit 5 hours ago [-]
Setuid binaries existing in 2025 is not acceptable. There needs to a movement to remove all of them as time and time again it's shown that it leads to severe vulnerabilities.
nmz 5 hours ago [-]
If you're worried about security, A less than 10k lines of SOC is your aim. mtm, abduco, dvtm achieve this. screen? Impossible for it to ever be secure. You'll be playing an endless game of whack-a-mole.
lionkor 5 hours ago [-]
lines of code is a measure of complexity in your argument; its better to call it that. Increased complexity, depending on the language, isn't necessarily lines of code, but can have the same effect
mistrial9 9 hours ago [-]
so it appears that packaged Debian `screen` is not installed with root execution, therefore this entire situation is not a problem on Debian?
TacticalCoder 2 hours ago [-]
[dead]
Pxtl 4 hours ago [-]
Can screen just get completely tossed and converted into a compatibility-layer wrapper around tmux?
lowbloodsugar 5 hours ago [-]
In 1990 we got told to stop using screen because other people could get into your sessions. Never used it again after that.
9 hours ago [-]
anthk 7 hours ago [-]
Then:
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.
Trasmatta 9 hours ago [-]
Only tangentially related, but I'm always fascinated that mailing lists are still a thing in 2025.
teddyh 9 hours ago [-]
Please, inform us of an alternative which is:
• Non-proprietary
• Federated
• Archivable
• Accessible
• Not dependent on a specific company
Eduard 2 hours ago [-]
- horrible usability
- can only participate in conversations via e-mails
- unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox
- NOT accessible, especially in the disabilities sense
- doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability
- no responsive design, tiny text and horizontal scrolling on mobile phone screens
- sends you your password in cleartext via e-mail
- actually complicated to unsubscribe from a list / manage your membership
Trasmatta 9 hours ago [-]
I wasn't criticizing the use of them, I just find it fascinating that we still use them. They'll probably still be around in some form in another 3 decades.
walterbell 9 hours ago [-]
Email is a root-of-trust for authentication in most non-email systems.
zoobab 8 hours ago [-]
GIT promised to be "Non-proprietary, Decentralized" but still does not have a built-in issue tracker :-)
HappMacDonald 8 hours ago [-]
GIT is non-proprietary and decentralized so it keeps that promise.
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.
graemep 7 hours ago [-]
Fossil has one. If its something you want use Fossil - which I think is a great alternative for small teams, on the other hand, this is probably not something large teams (which are a high priority for git) want.
jbaber 1 hours ago [-]
If I ever get around to writing my git issue tracker, everything will be stored in a completely separate reponame-issues.git
somat 8 hours ago [-]
Shouldn't the git native issue tracker be as simple as adding file pr/the_problem_i_am_having
badmintonbaseba 8 hours ago [-]
Issues shouldn't really live in the same source tree, IMO. But AFAIK there are forges that keep the issues in the same repository, just not in the same tree of commits that the source tree has, git notes style.
rixed 6 hours ago [-]
Any user without commit permission should be able to create tickets and comment on them.
What's wrong with debbugs? :)
delfinom 8 hours ago [-]
For large projects like the Linux kernel as an example out of many, I would assume the built-in issue tracker would end up 100x the size of the code base in storage space. lol
KolmogorovComp 9 hours ago [-]
My qualm against them is rather different. Why, after so much time, are they still so user-hostile, both in their web appearance and more generally usage?
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.
skydhash 8 hours ago [-]
I don’t think GitHub adds that much over using and contributing to software. I generally prefer when the project have its own website and a proper about and documentation section.
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.
jzb 8 hours ago [-]
"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."
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.
int_19h 12 minutes ago [-]
Try opening that link on a phone. You get tiny, hard-to-read text because of course it's monospace with hardcoded line breaks.
GP's point is that convenience and long-term thinking don't have to be an either-or. We should have convenient tools that don't require proprietary silos but work well on today's devices and with today's use cases.
mistrial9 8 hours ago [-]
> The long term absolutely matters and projects choosing convenience today
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`
immibis 8 hours ago [-]
A mailing list is just a kind of public group chat. You're probably in many public group chats, including this one right now. Mailing lists, IRC, traditional web forums, Discord, WhatsApp are all implementations of the same basic concept.
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.
WesolyKubeczek 5 hours ago [-]
> 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.)
Haven't you heard about the abomination which is Office365? They recently bolted emoji reactions onto email!
phyzix5761 7 hours ago [-]
I brought up some security issues similar to these years ago to the Screen community and they laughed at me saying I was being paranoid. Nice to see they're finally doing something about it.
> 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.
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.
https://sources.vsta.org/comp.sources.unix/volume10/screen/
* 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.
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.
https://jdebp.uk/FGA/bernstein-on-ttys/cttys.html
Tbf, they are probably all dead now anyway.
Really, the gall to complain about "laziness" when all you're doing is spreading negativity on a forum.
This. I have tried switching away from screen a few times. But failed because the keybindings are burned into my brain as well.
I will try harder.
If screen is there and I need to do something that lasts longer than my ssh session, screen is what I reach for. If it’s non-interactive, I reach for nohup next.
With that being said, the binary is huge. I get that zellij is statically linked, but tmux is about 900KiB and has minimal dependencies. I'm flabbergasted that a terminal multiplexer, stripped, is 38MiB.
I occasionally have to recalibrate my units. I just launched Emacs on my Mac and it's using 350MB of RAM. That's astonishing when I think about Amiga programs I wrote, but it's also just 0.53% of the RAM in this particularly machine. It's probably larger than it could be if someone ruthlessly trimmed it back, but I'd rather spend that time using the other 99.4% of my machine to do more fun stuff.
Regarding memory usage, Zellij appears to take up 63 MiB versus tmux's 3.8MiB. It's nice and all, but quite a pig. This is on Linux, maybe Mac is different.
But on desktop systems, on my Mac, Zellij takes 28MB of disk and 40MB of RAM. That's 1/37,000th of my available disk and 1/1,600th of my RAM. I'm all for optimized, tiny apps, but those are below my attention threshold.
Also note that computers with much less disk space than 128 Mb could and did run full-fledged GUI apps in the past. For example, the entirety of Windows 95 is ~100 Mb when installed.
Or is it more of a fish vs. zsh type of situation, where neither is obsolete, but the target audience is just very different?
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.
That’s been a pretty standard feature of tmux since forever.
In fact the reason I first discovered tmux was because some Irssi (terminal IRC client) plugins used tmux to create additional panes for Irssi.
tmux is one of those tools that does a lot more than most people realise but the learning curve is steep and features aren’t easy to discover.
Zellij looks interesting but these days I mostly use tmux as a control plane rather than a terminal UI. So the enhancements of Zellij are wasted on me.
Byobu with tmux as backend is my go to solution if I want a multiplexer, for what it worths.
https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
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.
Not an emacs user, but for this, what does screen do that tmux can't?
I switched to tmux eventually though.
Ubuntu it's not set.
CVE-2025-46802 can impact earlier releases, but all the other vulnerabilities are for the latest.
Not surprised to hear it's full of security holes. :)
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://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
https://security.opensuse.org/2025/05/12/screen-security-iss...
http://www.zoobab.com/screenrc
GNU need a better issue tracking system :-)
https://undeadly.org/cgi?action=article&sid=20090712190402
Turns out, it has features dependent on setuid, and some systems ship it that way? Yikes!
(But, after I gave u+s to screen, it reads root's ~/.screenrc instead of mine (which I accepted as part of the workaround). Maybe that particular build of screen I'm using doesn't react properly to setuid; maybe it has to be built a certain way also to enable that support.)
Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?
If 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.
I've seen how that mindset has ruined several companies. Not saying that you're wrong about that particular program that is, after all, free software replaced by other free software parts. But for business, it's lethal.
Joel Spolsky had a nice piece about it:
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
That and Fire and Motion seem to be forgotten wisdom already:
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
I feel old :-)
If you want a rethinking of the idea: zellij.
I prefer the latter. It matches my mental model of such things, and lots of people talk about enjoying switching to it. Many others happily use the former daily.
I've had some luck with mosh, but that also seems kind of moribund.
https://mosh.org
For my use case it's fine.
https://git.savannah.gnu.org/cgit/screen.git/tree/src
A few 2kLOC files and the rest is rather small.
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.
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.
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.
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
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.
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.
USB is a serial BUS, which allows multiple devices; serial ports are single device (if my memory serves).
2. How much money is in the industries that use those tools?
https://zellij.dev https://github.com/zellij-org/zellij
(Not a dev, just another end user.)
It could also be in my case that I use it so little that some latency is tolerable. I don't develop interactively in zellij or tmux. I mainly keep some logs tailing, and DB consoles open, etc, and I don't check them super often.
https://access.redhat.com/solutions/4136481
I would love to switch to a modern, maintained terminal multiplexer, but it would need to, well, be good at multiplexing.
No, the screen camp has the valid argument that licenses matter and tmux is not GPL software.
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.
• Non-proprietary
• Federated
• Archivable
• Accessible
• Not dependent on a specific company
- can only participate in conversations via e-mails
- unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox
- NOT accessible, especially in the disabilities sense
- doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability
- no responsive design, tiny text and horizontal scrolling on mobile phone screens
- sends you your password in cleartext via e-mail
- actually complicated to unsubscribe from a list / manage your membership
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.
What's wrong with debbugs? :)
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.
GP's point is that convenience and long-term thinking don't have to be an either-or. We should have convenient tools that don't require proprietary silos but work well on today's devices and with today's use cases.
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.
Haven't you heard about the abomination which is Office365? They recently bolted emoji reactions onto email!