The actual header on the page is

> We are building the multiplexer for all work.

imo this would have been a better way to do the HN submission title (with or without [terminal])

> Superlogical: We are building the [terminal] multiplexer for all work

I clicked on the link and read the page, but I still don't have the faintest idea what a "multiplexer for all work" is, or why I want one. The more I read about it, the less I understand about it. Guess I'm not the target audience. At least I know that now, after several minutes of reading and head-scratching.

I almost get tmux -- although I still don't understand why it's better than simply opening multiple terminal window instances like I've always done in Windows -- but I'm struggling to see how the concept of terminal multiplexing applies elsewhere.

With tux the biggest difference and gain is that you can detach and resume the terminal session, leaving processes running on the "server" (where tmux was initially started) even if your "client" disconnects. On top of this, you can have multiple terminals inside the same session.

So it's like launching processes with nohup?

By default, SIGHUP has no signal handler, and so a process that receives it will exit. The kernel should send SIGHUP to all child processes when you quit the shell session or the terminal file (pty/tty) is closed. Processes trying to write to a nonexistent terminal may be terminated by SIGPIPE.

So you launch a process with nohup(1). This puts SIGHUP and others on ignore status, redirects output to a file, and then executes your process. This is similar to how a daemon starts, when it explicitly dissociates from any terminal device.

With tmux or screen, a layer of pseudo-ttys (ptys) is created, and process groups are managed, so your terminal's pty is only connected to the master tmux process, and each subprocess/window is assigned a new pty and process group of its own, as if you had remotely logged in to each shell.

So tmux is now handling SIGHUP and can detect when your terminal or session closes out. The persistence of subprocesses comes from the fact that they aren't receiving SIGHUP and that they are still associated with pty, as tmux is running "daemonized" until you reattach.

Yes, except if you launch a process with nohup, then close your terminal and open a new one how do you reconnect to it? I assume there's a way to do it but I don't know how (probably someone with more unix-fu will reply), plus you can't see the previous output. Whereas with screen/tmux you can just pop it open again and see the whole session.

Tmux only makes sense if you’re connecting remotely in some form or another. Otherwise, it’s just terminal windows/tabs with extra steps. Even if your terminal integrates with tmux like iterm2 does (where local tabs become tmux tabs, local windows become tmux windows, etc), it doesn’t really mean much if it’s all local anyway.

The usual arguments make no sense if you’re only on your local machine:

- You can detach the session: well yeah, I can minimize the terminal window too.

- You can have multiple tabs/windows in a session: yup, same with my window manager

- You can keep multiple sessions and attach/detach from them whenever: I can do that with multiple desktops in my window manager

And so on.

But, once you want to do all of this on a remote server, it all makes sense: putting my laptop to sleep shouldn’t end the session on the server. If I get disconnected for some reason, I should be able to reattach and resume it if I reconnect. So then you have the session run on the server and you only “attach” to it when you connect, and if your terminal has good integration, new tabs become new tmux tabs etc… it’s all transparent.

It’s also useful if you’re running a session locally but anticipate wanting to attach to it from somewhere else: if your terminal session is tmux from the start, you can transparently attach to it from another machine too.

But, if you’re just dealing with one machine, who cares, just skip the multiplexer. (It’s literally not “multi” plexing if there’s only one client!)

Another thing worth mentioning is that if your terminal doesnt have good tmux integration, and you’re only running locally anyway, your life is strictly worse off with tmux: scrolling is a horribly broken hack, buffer search sucks, copy/paste never works, switching open terminals is an awkward ctrl+b contortion, etc. No amount of fiddling with your tmux config is going to make the UX as good as a decent terminal has, and I will die on this hill. :-)

Tmux is good because: 1) sessions stay running if you disconnect 2) window management - you can split your screen, have an octobox a-la redzone style, and focus/unfocus etc.

This is based on developing on a remote server - but even locally, I find it invaluable. Multiple terminal windows are fine, but some times you want multiple windows. Even in a pre-ai world, you might want to run a process, see the code, edit, and maybe have htop or something like that. If you ever NEED multiple terminal windows for the same thing, tmux is really the answer.

One reason I find it hard to grasp is that when I work on Windows, it's almost always through RDP or VNC. There is never any question of a terminal (or a process launched from it) staying open between login sessions, because it never depended on any particular connection to begin with. It's just there, on the desktop, which might stay up for months before I need to connect to it again. Any terminals or other processes I launch on that system will be there until I close them intentionally, or until Microsoft decides to reboot the system without my permission.

So when I dip my toes into the Linux world, the first thing I do (or rather ask an LLM harness to do, being much less familiar with Linux than I am with Windows) is set up an RDP host. That way I can follow the same basic workflow on both OSes. I don't need to do anything special with terminal windows.

I guess if I were running truly headless systems that don't even have a VGA frame buffer, I'd be more interested in multiplexing. But so far I haven't had to do that, and would probably resist it because a persistent desktop strikes me as better in general than letting applications including terminals worry about their own lifetimes.

Same, at first, I thought it would be something like Glean for enterprise information joining to follow feature delivery or something and then I saw terminal and I gave up.

Same here, no clue what this is even about lol

If you're using Windows you're likely not the audience. Which is fine.

Not really; not without understanding what am I missing. Why does Linux need a "multiplexer for all work," while Windows either already has one, doesn't need one, or couldn't use one?

A Multiplexer let's you run multiple terminals in one window, this is a new one. WindowsOS does not get as nice of tools as Linux generally.

After using a tiling WM, it feels like this is a window manager job. It even works for non-terminal applications.

Multiplexer works without any WM installed, which is nice.

Except you don't need a multiplexer for that. Essentially all modern terminals have tabs. Many have split-screen. Even windows ships with a half-decent terminal with tabs and multiple panes by default now!

A multiplexer's job is to do the whole multiple tabs/panes/windows thing independently of the terminal itself, but (a) the UX for eg. tmux is so much worse than that of a good terminal UI, and (b) you only need that if you plan on connecting remotely (see my other comment https://news.ycombinator.com/item?id=49108483).

website is very vague - not useful content - no information, some gradient box without any content, team thats it. Super annoying landing page. Even if HN title is not descriptive the website is not helping to figure out what this is all about.

One of the worst I've seen was title editorialized from original "Someone: something [x.com]" to just "Something [x.com]".

Without clicking you’d never know why it’s the title.

that's kinda the point -- titles on HN usually indicate the sort of content that's behind clicking through, and whether it might be something interesting to the prospective reader. this one doesn't because it's the name of the company.