> 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.
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.
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:
* 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.
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.
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.
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.
If the keys and functionality don't work exactly as GNU Screen does then this won't help me. The behavior and keystrokes are so far burned into my brain that it doesn't make sense at this point to learn a new tool unless/until every system I use under the sun doesn't support GNU Screen anymore.
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.
They re-keyed it specifically so it could be nested, however, they mention the prefix key is intentionally dumb and ment to be remapped, probably to ^a like screen.
^a is the worst for emacs users since ^a is begging-of-line which we use a ton.
When I first started using screen some years ago the emacswiki (I think) even mentioned it and recommended to remap it to ^p which it is for me for screen and tmux since then.
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.
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.
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.
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.
> I'm surprised there's room for tmux on something that tiny.
A question that comes to mind is, under what circumstances would you expect a TUI based program that processes streaming text not to fit on a system that is otherwise capable of user interaction? It seems vaguely in the vicinity of the simplest possible interactive task you could come up with.
Certainly it generally isn't worth hyper-optimizing mainstream desktop applications to wring out the last few MB, let alone KB, of RAM in this day and age. However that doesn't answer the question - why would more than 1 MB of program binary be required for multiplexing text in a terminal? At least at first glance it honestly seems a bit outlandish.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. :)
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.
I use screen almost by default when connecting over SSH, but I've never used -x and didn't know about it.
Habbit from back in the dial-up days when connections got dropped quite frequently. Still relevant with laptop going into sleep mode and such.
So nice to just resume wherever you were as of nothing happened. Or to run jobs in the background, like long compiles, without an additional SSH session.
The risk is anything else dropping your connection while an interactive long-running process is going. You can nohup, or run inside something like screen/tmux,
You're not wrong, but largely in the virtualized world we live in, it matters less and less when you have a virtual console.
That said the sshd session you are connected on is still running the old executable until the service is restarted AND your session ends, so even if sshd gets upgraded, you should still be good to go.
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 :-)
Glacial page bedrock of an OS with optional sandboxed more-up-to-date userspace packages and runtimes that can be layered on top of the host system was the dream of flatpak/snap/appimage, right?
Yes, though that comes with its own headaches since the data those sandboxed applications are supposed to touch are the only actually valuable data on my computer. (How many versions of OpenSSL are currently running on my Silverblue system? I literally couldn't tell you.) My spreadsheet is only vouched for by some random dude on Flathub and it can steal all my financial information. But at least it can't add a printer, or delete a system file that I can freely download from the Internet at any time.
This a decent observation, but I would add that some other Flatpak app that you run might be correctly sandboxed from accessing your financial information, and this is the real benefit of such a system.
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.
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.
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.
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.
To be clear for the sake of other readers, Debian's firefox-esr package is Firefox.
It's simply a release from Mozilla's Extended Support Release channel, as distinct from the Rapid Release channel that you are apparently using. Not a different project/product.
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.
This is a problem with quite a few older projects, that issues get buried in the endless depths of unindexed mailing lists, if at all. People bemoan Discord (rightfully) for making info like this unaccessible, but IRC (that some projects still use) is basically twice as bad.
I really wish these projects would migrate to Gitea/Forgejo/Codeberg, GitLab or GitHub or anything like that, just to bring these things together and provide vital discoverability.
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.
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.
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.
Last time I looked at Zellij it looked like a great new project in the multiplexer ecosystem, but didn't support a purely keyboard-driven copy/paste mechanism. I use that extensively and couldn't do without. So tmux it is until that gets added.
Yeah, I also use that all the time. I use the terminal because I want to use my keyboard, not the mouse. And copy / pasting is something I do very very often. So I don't understand why people make a terminal multiplexer and don't add this feature.
In screen & tmux you can also use vim shortcuts to navigate the scrollback buffer. That is so convenient and makes me work so fast. I can search for a snippet close to where I want to copy some text, and then navigate more precisely with the vim shortcuts.
So that's the first thing I look for in a terminal multiplexer, because if you're gonna expect that I'm gonna put my right hand off the keyboard and use the MOUSE to awkwardly select some text in a TERMINAL, then you expected wrong.
I had the same when I was trying out tmux first time. But eventually I configured tmux to very closely match screen's shortcuts. Just a few things are different, but I got back some extra features and plugins from tmux with it.
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?
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.
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.
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.
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.
> 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 guess, but does it really get in the way?
I use tmux only for scrollback and having multiple "tabs" and sessions, and not much else. But the more advanced stuff like splits and whatnot never really get in my way.
If there was a way to get rid of Tmux's persistent status bar, I'd be happy to switch over. But last time I checked, you can't, and I want that real estate.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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).
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.
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.)
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'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.
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.
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.
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).
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.
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.
You can run screen as setgid instead. Fedora sets up a system group called screen and installs screen as setgid so that the multiuser functionality works but cannot be accidentally used to do things as root.
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.)
Nope, setuid programs have an effective UID as the owner (often root), but also have the real user ID of the original user. Programs intended for setuid operation pay attention to this; it is very important. They can use to to perform certain operations under privilege and then permanently drop to the original user.
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...
If we're talking about someone who has received a binary copy of software, then isn't this obvious?
The MIT license permits the distributor to close the source of what they've redistributed, in original or modified form. Potentially depriving the end user of the freedom to view/modify/distribute the source.
Permissive licenses prioritize rights of the software redistributors at the expense of the end users.
The MIT license permits some other developer to fork the source and close it off, but as an end user of this particular software that is under MIT (meaning that source is available, and I can take it and modify it if I need to), how does that affect me?
tmux is MIT-licensed, right? The MIT license is very similar to the (3-clause) BSD license which makes it upward-compatible with the GPL (you can incorporate MIT- or BSD-licensed code with GPL-licensed code).
Edit: and to your point of a distributor withholding the source: yeah, so? If there ever came a point where the current maintainer closed its source (unlikely), somebody with a copy of it can step in with a fork. Or the project can die a deserved death for closing its source. At this point the benefits of open source are pretty much obvious to anyone with a brain, and closing the source of an open-source project is practically suicide.
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.
A long time ago tmux was a little bit slower. But if you say that it's super slow for you now, then probably it's something to do with your config / setup.
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?
The terminal sessions will persist even if your emulator crashes. Or, if you ssh into a machine you can use multiple terminal sessions from a single connection, and you can disconnect and reconnect to those sessions later.
There's a few other features like a common clipboard of sorts, monitoring a session for silence/activity, but those could all be provided by your emulator.
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.
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
I do use abduco and dvtm, however, there is one major flaw in splitting the persistence and the emulator/multiplexer: if you detach, then reattach with a different terminal, with different capabilities, the emulator (which is running in abduco, say) doesn't know that it has to render differently.
Compared to tmux, which knows this, and can adjust the rendering to suite the new terminal.
Isn't this a bug of the software and not of the technology?
refetching terminfo capabilities seems an easy fix, you also get sigwinched which I imagine happens on a new terminal.
Mind you, I don't use abduco but do use dtach sometimes, I've accepted that I need screen and tmux with all its warts, like instead of using a scripting language like TCL/Lua for configuration it built its own frankenstein language that is severely limited.
Most terminal emulators have no way of reporting their capabilities at run time. And having dtach or abduco modify the TERM environment variable of the already spawned child is not possible, and even if it did, there is no standard way to get the child to reread it.
So, no, the tech is kinda broken. The only correct thing to do is to have the attaching program also do terminal emulation (or, assume that you always attach with a compatible terminal).
You could make it a simpler form of emulation, and then have the more complex muxing ability as a separate program, at the cost of having to go through multiple emulation layers.
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.
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.
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.
> 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!
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.
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.
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
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.
The web has horrible usability if you use a text-based browser. I.e. if you use a mail reader with good usability, a mailing list has good usability. This is a client-side issue, not a technology issue.
> - can only participate in conversations via e-mails
Um, yes, a mailing list uses e-mail. I don’t know what you expected.
> - unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox
If you are a new user, and want to reply to a mail you read in the list archive, just write a new mail; there is no strict rule that any discussions must be restricted to one thread.
Indeed, if you want to start a new discussion after some time has elapsed, a new thread may be preferred.
> - NOT accessible, especially in the disabilities sense
Again, this is a client issue. I believe that e-mail is actually the preferred form for those with accessibility needs.
> - doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability
Somewhat true, but this depends on the list – some list archives do feature search – and is very rarely a problem in practice, since external search engines are very efficient.
> - no responsive design, tiny text and horizontal scrolling on mobile phone screens
Again, a client issue. Get a better e-mail client.
> - sends you your password in cleartext via e-mail
Yes, many lists do this, but this is not a requirement of the technology. Some lists could require all your mails to be signed with PGP or S/MIME; it is entirely up to the list.
> - actually complicated to unsubscribe from a list / manage your membership
Not really. The ”List-Unsubscribe” header is commonly sent in every mail to the list.
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.
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.
"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.
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.
You will inevitably need to use the website at some point to find past discussions about such and such. And, somehow, all mailing list software seems to have this kind of web UI.
But also, part of the problem is the use of email lists. Or rather, specifically, plain text emails, because they contain pre-wrapped lines, and users often assume monospace font. You can try to reflow, but in general it's not possible to determine whether any given line break is there because the line just needed to be wrapped, or because it's actually meaningful (for code, diagram etc).
> 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`
Nice write-up.
> 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.
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.
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:
https://sources.vsta.org/comp.sources.unix/volume10/screen/
I guessed something similar. Screen is from an era where setuid was pretty common!
[flagged]
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.
[flagged]
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.
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.
Cheers, that's interesting. There are a few instances of ([]) which look like broken links in:
https://jdebp.uk/FGA/bernstein-on-ttys/cttys.html
Tbf, they are probably all dead now anyway.
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.
[flagged]
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.
[flagged]
[flagged]
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.
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.
SvP https://github.com/grml/grml-etc-core/blob/master/etc/tmux.c...
If the keys and functionality don't work exactly as GNU Screen does then this won't help me. The behavior and keystrokes are so far burned into my brain that it doesn't make sense at this point to learn a new tool unless/until every system I use under the sun doesn't support GNU Screen anymore.
Thankfully you can configure it. I had the same initial difficulty.
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.
If you don’t care about the output or handle it manually, use detail over nohup, it’s a bit nicer.
> 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.
I will try harder.
I’m not sure what the screen keybindings are anymore but you could always rebind the tmux key so.
They re-keyed it specifically so it could be nested, however, they mention the prefix key is intentionally dumb and ment to be remapped, probably to ^a like screen.
^a is the worst for emacs users since ^a is begging-of-line which we use a ton.
When I first started using screen some years ago the emacswiki (I think) even mentioned it and recommended to remap it to ^p which it is for me for screen and tmux since then.
(I could remember something wrong here)
I mapped to alt space, which breaks things some times ten years on, but I just drop whatever is bound to that key in my DE and move on.
I've just worked '^a a' into my terminal emacs muscle memory.
Screen is useful when you need to a nest multiplexing inside tmux.
And for serial ports
A similar process is happening with zellij and tmux. Since I switched over I feel that tmux is obsolete.
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.
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.
Hopefully some effort is eventually put into slimming things down.
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.
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.
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.
> I'm surprised there's room for tmux on something that tiny.
A question that comes to mind is, under what circumstances would you expect a TUI based program that processes streaming text not to fit on a system that is otherwise capable of user interaction? It seems vaguely in the vicinity of the simplest possible interactive task you could come up with.
Certainly it generally isn't worth hyper-optimizing mainstream desktop applications to wring out the last few MB, let alone KB, of RAM in this day and age. However that doesn't answer the question - why would more than 1 MB of program binary be required for multiplexing text in a terminal? At least at first glance it honestly seems a bit outlandish.
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.
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.
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?
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.
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.
> 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.
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.
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.
Among a certain subset of linux users, new is always better.
Terminals are obsoleted by Arcan:
https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
From a quick read, all I can see is a manifesto for emacs.
How though? Genuine question; x11 didn't obsolete terminals. Does Arcan do something X11 couldn't?
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.
Nah, screen's main use case is as an ad-hoc method to daemonise random scripts.
Let's see, we have at least daemonize[0], nohup[1], and disown[2] for that. Some discussion of the differences: https://unix.stackexchange.com/questions/3886/difference-bet...
[0] https://github.com/bmc/daemonize
[1] https://linux.die.net/man/1/nohup
[2] https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash....
A more modern alternative is systemd-run: <https://www.freedesktop.org/software/systemd/man/latest/syst...>
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”
I switched to dtach for the first case.
dtach for session persistence. “Do one thing well.”
> 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?
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.
Nothing but replacing it with something newer invalidates decades of muscle memory.
I switched to tmux eventually though.
I'm confused by this statement. Are you claiming this is the projects' stated goal? Their primary use in the wild?
Emacs can work as a daemon.
It also has tramp mode which means you can use all your local packages remotely.
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.
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.
On my sistems screen doesn't have setuid.
Same here (speaking more specifically about debian)
On my gentoo box it's setgid hmmm.
Ubuntu it's not set.
Nostalgia and novelty are powerful narcotics.
Engineers are rational people. Software developers calling themselves "engineers" are not.
IDK Man the hammer I use today looks a hell of a lot like the hammer used by engineers throughout human history.
Is it actually in common usage? I'm sure it's used by a lot of people, but it seems quite niche still.
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.
Sysadmin types, often daily
True, it's not really as if it's a massive codebase
We usually wait for a version written in Rust for this kind of cruft removal.
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.
In the EPEL versions of screen, I am seeing the setgid bit set only. I am guessing that later versions setuid to root?
Edit: Yes, Screen 5.0.0.CVE-2025-46802 can impact earlier releases, but all the other vulnerabilities are for the latest.
The original writeup by the OpenSUSE security team laid this out better:
https://security.opensuse.org/2025/05/12/screen-security-iss...
Different distros built it in different ways, affecting level of vulnerability to the different issues.
This "explanation" only makes it sound worse - why would you even consider setuid if you do not completely understand ever detail of the code base.
screen has used setuid root for multiuser for at least 20 years. Used to use it in multiuser for remote pair programming.
I remember installing screen on a SunOS box back in the early 90's. It's been around a longggg time.
I guess I'm glad that I switched to tmux ages 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. :)
You can get close to the same experience with tmux.
https://superuser.com/questions/188501/is-there-a-way-to-hav...
Use groups instead of chmod 777.
Yup, screen -x
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.
I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
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.)
I use screen almost by default when connecting over SSH, but I've never used -x and didn't know about it.
Habbit from back in the dial-up days when connections got dropped quite frequently. Still relevant with laptop going into sleep mode and such.
So nice to just resume wherever you were as of nothing happened. Or to run jobs in the background, like long compiles, without an additional SSH session.
Often for long running jobs you want to see the status of where logging out of the system stops the job output.
Or where you can't risk dropping the terminal session, like during a system upgrade via SSH.
System upgrade shouldn't drop your session btw, at least not on most flavors I'm familiar with
The risk is anything else dropping your connection while an interactive long-running process is going. You can nohup, or run inside something like screen/tmux,
You're not wrong, but largely in the virtualized world we live in, it matters less and less when you have a virtual console.
That said the sshd session you are connected on is still running the old executable until the service is restarted AND your session ends, so even if sshd gets upgraded, you should still be good to go.
A thoughtfully designed upgrade system doesn’t do the real work side your terminal session in the interactive process.
Defense in depth is always valuable. The point of this thread is that screen protects your workflow from an unexpected disconnection.
Note: In Debian, GNU screen is not installed with setuid-root privileges.
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 :-)
Debian stable users missed heartbleed entirely. I think the glacial pace is underrated.
> Debian stable users missed heartbleed entirely
Missed it? Not at all, Debian pioneered that style of bugs years before!
https://github.com/g0tmi1k/debian-ssh
And the default SELinux config was broken for like 15 years IIRC. It's always pick your poison.
Glacial page bedrock of an OS with optional sandboxed more-up-to-date userspace packages and runtimes that can be layered on top of the host system was the dream of flatpak/snap/appimage, right?
Yes, though that comes with its own headaches since the data those sandboxed applications are supposed to touch are the only actually valuable data on my computer. (How many versions of OpenSSL are currently running on my Silverblue system? I literally couldn't tell you.) My spreadsheet is only vouched for by some random dude on Flathub and it can steal all my financial information. But at least it can't add a printer, or delete a system file that I can freely download from the Internet at any time.
This a decent observation, but I would add that some other Flatpak app that you run might be correctly sandboxed from accessing your financial information, and this is the real benefit of such a system.
Related... https://bugzilla.mozilla.org/show_bug.cgi?id=1966096
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.
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?).
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.
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.
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.
To be clear for the sake of other readers, Debian's firefox-esr package is Firefox.
It's simply a release from Mozilla's Extended Support Release channel, as distinct from the Rapid Release channel that you are apparently using. Not a different project/product.
https://support.mozilla.org/en-US/kb/choosing-firefox-update...
Slackware 15:
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
FWIW, Slackware 15 was updated to screen to screen-4.9.1.
This update fixes security issues:
* attacher.c - prevent temporary 0666 mode on PTYs.
* avoid file existence test information leaks.
* socket.c - don't send signals with root privileges.
Damn, Slackware. That’s a name I haven’t heard in a very long time.
Likewise in Gentoo. But in Gentoo it has SETGID for utmp group. Though I'm not sure what the implications are.
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.
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.
I set TMPDIR to $HOME/tmp because of that.
Except for the name, TMPDIR is unrelated to utmp.
I know; but it mitigates some potential race conditions.
More info on that?
Looks like it is in Fedora.
On Fedora it is setgid screen, not root.
I wonder if there is some selinux policy to reduce the attack surface
There almost certainly is, pretty sure Fedora has an SELinux policy for all software in base.
Likewise in Arch.
Here's the rendered blog post:
https://security.opensuse.org/2025/05/12/screen-security-iss...
I emailed the author of GNU Screen about the lack of proper documentation about the logging to a file feature:
http://www.zoobab.com/screenrc
GNU need a better issue tracking system :-)
There was a Q&A with the author of Tmux. He was complaining about the lack of documentation ~16 years ago.
https://undeadly.org/cgi?action=article&sid=20090712190402
Tmux has been in OBSD base side several releases and documented since the first one.
I know. I suggest you read the Q&A I posted.
It is documented in detail in the GNU screen manual, https://www.gnu.org/software/screen/manual/screen.html#Log
> GNU need a better issue tracking system :-)
This is a problem with quite a few older projects, that issues get buried in the endless depths of unindexed mailing lists, if at all. People bemoan Discord (rightfully) for making info like this unaccessible, but IRC (that some projects still use) is basically twice as bad.
I really wish these projects would migrate to Gitea/Forgejo/Codeberg, GitLab or GitHub or anything like that, just to bring these things together and provide vital discoverability.
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.
https://zellij.dev https://github.com/zellij-org/zellij
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.
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.)
No, haven't tried recently, but will make a note to do so. Agree that a couple of years is an eternity :)
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.
Last time I looked at Zellij it looked like a great new project in the multiplexer ecosystem, but didn't support a purely keyboard-driven copy/paste mechanism. I use that extensively and couldn't do without. So tmux it is until that gets added.
Yeah, I also use that all the time. I use the terminal because I want to use my keyboard, not the mouse. And copy / pasting is something I do very very often. So I don't understand why people make a terminal multiplexer and don't add this feature.
In screen & tmux you can also use vim shortcuts to navigate the scrollback buffer. That is so convenient and makes me work so fast. I can search for a snippet close to where I want to copy some text, and then navigate more precisely with the vim shortcuts.
So that's the first thing I look for in a terminal multiplexer, because if you're gonna expect that I'm gonna put my right hand off the keyboard and use the MOUSE to awkwardly select some text in a TERMINAL, then you expected wrong.
Thats nice and all, but I really, really like screen and its commands are burned into my muscle memory. I've been using it for more than 20 years.
I had the same when I was trying out tmux first time. But eventually I configured tmux to very closely match screen's shortcuts. Just a few things are different, but I got back some extra features and plugins from tmux with it.
If you're interested I can share my config.
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?
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.
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.
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.
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 :-)
It's not large:
https://git.savannah.gnu.org/cgit/screen.git/tree/src
A few 2kLOC files and the rest is rather small.
What are the replacement tools I should be looking at as a casual user of screen?
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.
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.
https://mosh.org
For my use case it's fine.
> 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 guess, but does it really get in the way?
I use tmux only for scrollback and having multiple "tabs" and sessions, and not much else. But the more advanced stuff like splits and whatnot never really get in my way.
Along the lines of Mosh, I've migrated from it to Eternal Terminal (ET): https://eternalterminal.dev
If that is literally the only thing that you need, dtach is the ticket.
Even screen is too powerful for that use case. Just use nohup or dtach instead.
Screen has some obscure functionality that tmux doesn't have. Handling serial port connections, whereas with tmux AFAIK you'd have to use minicom.
Tmux
If there was a way to get rid of Tmux's persistent status bar, I'd be happy to switch over. But last time I checked, you can't, and I want that real estate.
Add "set -g status" to your tmux.conf. You can even bind it to a key to toggle if you want.
> 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.
Seems like a prime target for Jia Tan.
Yep, from the timeline it looks like lack of communication (and maybe also capabilities/resources/time/will, not sure) [0]
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.
TFA says upstream asked for the review.
Right, I got the direction wrong.
"TFA"?
The Fine Article
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.
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.
It's not sad if a good Stallman-free alternative exists. Like tmux.
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.
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.
True, this is why I switched to tmux.
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.
> 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.
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.
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.
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.
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.
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).
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'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.
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
What is a serial port and what do you use it for?
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.
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).
console=ttyS0,115200
Just use minicom
I'm sure a rewrite of screen in Rust will be 105% secure. And won't support serial ports either.
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.
Rendered version: https://security.opensuse.org/2025/05/12/screen-security-iss...
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.
Seeing screen popup reminded me of that one time I switched to tmux and forgot to use screen.
> The observed behaviour has been present in Screen versions since at least the year 2005.
and it's been an anti-pattern and covered by tools like rkhunter for around least that long, as well
but pretty sure screen was setuid root in the 90s too
1. How many developers run all the most popular open source tools?
2. How much money is in the industries that use those tools?
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.
You can run screen as setgid instead. Fedora sets up a system group called screen and installs screen as setgid so that the multiuser functionality works but cannot be accidentally used to do things as root.
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.
so it appears that packaged Debian `screen` is not installed with root execution, therefore this entire situation is not a problem on Debian?
[dead]
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.)
Nope, that's exactly how setuid works. You're setting the [s]pecial bit on a binary to tell the system to always run it as the provided [u]ser
Nope, setuid programs have an effective UID as the owner (often root), but also have the real user ID of the original user. Programs intended for setuid operation pay attention to this; it is very important. They can use to to perform certain operations under privilege and then permanently drop to the original user.
Can screen just get completely tossed and converted into a compatibility-layer wrapper around tmux?
So ... my tmux lifestyle is objectively superior in this one respect. Excellent.
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...
> 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.
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.
You seem to completely miss the point of the GPL.
You're welcome to explain it to me. What benefits do I get from switching from MIT software to GPL one as an end user?
In your view of the world what is an end user?
If we're talking about someone who has received a binary copy of software, then isn't this obvious?
The MIT license permits the distributor to close the source of what they've redistributed, in original or modified form. Potentially depriving the end user of the freedom to view/modify/distribute the source.
Permissive licenses prioritize rights of the software redistributors at the expense of the end users.
https://en.wikipedia.org/wiki/Copyleft#Freedom
The MIT license permits some other developer to fork the source and close it off, but as an end user of this particular software that is under MIT (meaning that source is available, and I can take it and modify it if I need to), how does that affect me?
tmux is MIT-licensed, right? The MIT license is very similar to the (3-clause) BSD license which makes it upward-compatible with the GPL (you can incorporate MIT- or BSD-licensed code with GPL-licensed code).
Edit: and to your point of a distributor withholding the source: yeah, so? If there ever came a point where the current maintainer closed its source (unlikely), somebody with a copy of it can step in with a fork. Or the project can die a deserved death for closing its source. At this point the benefits of open source are pretty much obvious to anyone with a brain, and closing the source of an open-source project is practically suicide.
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.
Server? I never encouter that while using tmux.
You can just use one session if you like, and if you do, it's the default, so you don't have to do anything special.
Tabs and Windows work similar as in screen as far as I can see.
No, you can't. Using one session, every client have to show exactly the same panels with the same layout in the same terminal size.
I found it incredibly slow, especially running Neovim. Zellij was missing super basic functionality, so I went back to screen.
A long time ago tmux was a little bit slower. But if you say that it's super slow for you now, then probably it's something to do with your config / setup.
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?
I love GNU Screen, daily usage.
A good sign, that they called for help. Hope they can attract some more new developers, carefully maintaining it.
In 1990 we got told to stop using screen because other people could get into your sessions. Never used it again after that.
Are there any official RedHat CVE pages for any of these screen vulns yet? Haven't found anything so far
RedHat removed screen from the distro repos starting from RHEL8 and recommended tmux as the replacement.
https://access.redhat.com/solutions/4136481
It's still in EPEL I think but I guess that releases RH from having to address it?
That's right. EPEL is not an officially supported repo.
Everyone I know has switched to tmux a long time ago. Screen is obsolete and shouldn't be used
What advantages does screen offer compared with multiple tabs in your terminal emulator?
The terminal sessions will persist even if your emulator crashes. Or, if you ssh into a machine you can use multiple terminal sessions from a single connection, and you can disconnect and reconnect to those sessions later.
There's a few other features like a common clipboard of sorts, monitoring a session for silence/activity, but those could all be provided by your emulator.
Keyboard shortcuts for searching and copying text from the scrollback buffer.
Saving your sessions and tabs and restoring them after a reboot.
A consistent experience regardless of which terminal emulator you use.
I use it for running some multiple-hour jobs on a remote VM.
One big one is the multi-user mode
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.
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
I do use abduco and dvtm, however, there is one major flaw in splitting the persistence and the emulator/multiplexer: if you detach, then reattach with a different terminal, with different capabilities, the emulator (which is running in abduco, say) doesn't know that it has to render differently.
Compared to tmux, which knows this, and can adjust the rendering to suite the new terminal.
Isn't this a bug of the software and not of the technology?
refetching terminfo capabilities seems an easy fix, you also get sigwinched which I imagine happens on a new terminal.
Mind you, I don't use abduco but do use dtach sometimes, I've accepted that I need screen and tmux with all its warts, like instead of using a scripting language like TCL/Lua for configuration it built its own frankenstein language that is severely limited.
Most terminal emulators have no way of reporting their capabilities at run time. And having dtach or abduco modify the TERM environment variable of the already spawned child is not possible, and even if it did, there is no standard way to get the child to reread it.
So, no, the tech is kinda broken. The only correct thing to do is to have the attaching program also do terminal emulation (or, assume that you always attach with a compatible terminal).
You could make it a simpler form of emulation, and then have the more complex muxing ability as a separate program, at the cost of having to go through multiple emulation layers.
[dead]
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.
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.
Only tangentially related, but I'm always fascinated that mailing lists are still a thing in 2025.
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.
> 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!
Please, inform us of an alternative which is:
• Non-proprietary
• Federated
• Archivable
• Accessible
• Not dependent on a specific company
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.
Email is a root-of-trust for authentication in most non-email systems.
GIT promised to be "Non-proprietary, Decentralized" but still does not have a built-in issue tracker :-)
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.
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.
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
If I ever get around to writing my git issue tracker, everything will be stored in a completely separate reponame-issues.git
Shouldn't the git native issue tracker be as simple as adding file pr/the_problem_i_am_having
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.
Any user without commit permission should be able to create tickets and comment on them.
What's wrong with debbugs? :)
- 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
> - horrible usability
The web has horrible usability if you use a text-based browser. I.e. if you use a mail reader with good usability, a mailing list has good usability. This is a client-side issue, not a technology issue.
> - can only participate in conversations via e-mails
Um, yes, a mailing list uses e-mail. I don’t know what you expected.
> - unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox
If you are a new user, and want to reply to a mail you read in the list archive, just write a new mail; there is no strict rule that any discussions must be restricted to one thread.
Indeed, if you want to start a new discussion after some time has elapsed, a new thread may be preferred.
> - NOT accessible, especially in the disabilities sense
Again, this is a client issue. I believe that e-mail is actually the preferred form for those with accessibility needs.
> - doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability
Somewhat true, but this depends on the list – some list archives do feature search – and is very rarely a problem in practice, since external search engines are very efficient.
> - no responsive design, tiny text and horizontal scrolling on mobile phone screens
Again, a client issue. Get a better e-mail client.
> - sends you your password in cleartext via e-mail
Yes, many lists do this, but this is not a requirement of the technology. Some lists could require all your mails to be signed with PGP or S/MIME; it is entirely up to the list.
> - actually complicated to unsubscribe from a list / manage your membership
Not really. The ”List-Unsubscribe” header is commonly sent in every mail to the list.
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.
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.
"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.
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.
Yes, ideally for a web archive the text should be flowed and styling responsive. That’s a flaw of the web site not the use of email lists.
You will inevitably need to use the website at some point to find past discussions about such and such. And, somehow, all mailing list software seems to have this kind of web UI.
But also, part of the problem is the use of email lists. Or rather, specifically, plain text emails, because they contain pre-wrapped lines, and users often assume monospace font. You can try to reflow, but in general it's not possible to determine whether any given line break is there because the line just needed to be wrapped, or because it's actually meaningful (for code, diagram etc).
> 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`
I’ve never used a discord server and would not know how. If that’s the communication channel you choose, I’m out.
I have and can, but I strongly prefer not to, and will generally just avoid it altogether.
If I wanted to use IRC, I’d use IRC.