You Don't Need a Terminal Multiplexer on Your Desktop | Hacker News Reader

You Don't Need a Terminal Multiplexer on Your Desktop

xn--gckvb8fzb.com

40 pointsmatrixhelix40 comments

The argument here seems to be: “the features you like about terminal multiplexers should be built into your terminal emulator, or your window manager, or I don’t see why they are really necessary.” Plus some complaints about influencers.

Sure, I’ll just replace my perfectly functional window manager so I can avoid using a terminal multiplexer.

Except I’ll still want a terminal multiplexer on servers, so I still need to be familiar with the way the tool works and I’ll still be happier if I have a nice config (sidenote: the article complains about needing very complicated configurations, but tmux is fine with like… 10 lines of configuration? You can solve the problem of over complicated configs by just not doing them).

Overall it kind of feels like hipsterism or engagement bait. Complaining about “content creators” is a very popular way to show off your bona fides nowadays. I guess this is just going back and forth on “no, you are the influencer/engagement fisher” but I think tons of people have been using terminal multiplexers for decades because they are boring and practical. If someone made a YouTube or a TikTok about them, I guess… I dunno, let the kids have nice things too, <shrug>.

> Except I’ll still want a terminal multiplexer on servers

Biggest reason not to use a terminal multiplexer locally, imo: There is nothing worse than hitting Ctrl-b twice for every action when you're also using the muxer remotely.

This tmux config turns F12 into a button to toggle the local leader key. You remote into tmux and hit F12, and now your leader key gets sent to the remote tmux instead of the local.

I don't use tmux locally anymore; but I still use the same leader key as tmux in wezterm, and I have a wezterm script to toggle it with F12 just like tmux.

Maybe you'll like it too?

  bind -T root F12  \
    set prefix None \;\
    set key-table off \;\
    set status-style "fg=$color_status_text,bg=$color_window_off_status_bg" \;\
    set window-status-current-style "fg=$color_dark,bold,bg=$color_window_off_status_current_bg" \;\
    if -F '#{pane_in_mode}' 'send-keys -X cancel' \;\
    refresh-client -S \;\

  bind -T off F12 \
    set -u prefix \;\
    set -u key-table \;\
    set -u status-style \;\
    set -u window-status-current-style \;\
    set -u window-status-current-format \;\
    refresh-client -S

I just have Ctrl-a set as the primary, and on remote boxes (where I run a tmux which ends up running inside a pane in my local tmux) I use Ctrl-b. Took about 20 minutes to get the muscle memory to adjust for it and now 15 years later I'm still very happy with it.

You can remap the prefix key...

I think the point of their comment is that if you're constantly connecting to different remote servers, you're not going to want to have to change the config on each server remotely. It's the same argument for understanding base vi as well and honestly does come in handy, but it's very discipline specific, most people don't have to worry about this use case.

In that case you’d probably want to change your local config away from the default.

But this is all very silly, I mean, of course there are workflows that aren’t assisted by terminal multiplexers. I’ve heard rumors of jobs out there that don’t even use computers. Adding one more job to the pile that doesn’t need the tool doesn’t say anything about the cases where it does come in handy.

I prefer it, to the point that I also use the same pattern for my WM with remote and virtual sessions. Keeping the same uniform shortcuts everywhere and just nesting a prefix is a lot easier that having to remember what shortcuts work in what environments. Moving and styling the tmux bar can help (or hurt) keeping muscle-memory mapped to the level you're operating on. At some point, any other approach gets too cognitively complex as you roam and scale[0].

If you only have nested use-cases rarely (or avoid them because you find them cumbersome) I can see how it never sticks but maybe just try leaning into it. YMMV, ofc.

[0]: Please prove me wrong, I'm open to try (:

Yeah, nested is a headache. The terminal use to connect to the server doesn’t have a tmux session running locally. That would be a nightmare.

I don't really buy the "I need multiple terminal sessions remotely" argument. It's just as easy to have multiple terminal emulator windows remoted into a server as it is to have multiple windows on a local session.

No it wouldn’t be just as easy.

Source: this is a description of my own workflow and preferences, so I’m the ultimate authority on the subject, haha.

> Source: this is a description of my own workflow and preferences, so I’m the ultimate authority on the subject, haha.

It's fine to choose your workflow by whatever criteria you decide, but on a post about workflows on a discussion forum, it's reasonable for mvdtnz to continue that discussion and not be laughed at for doing so.

I agree that tmux or screen is a must-have tool for servers.

But you certainly didn't read it all, or at least to the point where he goes more in depth of how crazy the working with Zellij is. After reading the parts of the interview with its author I'm not even going to check its webpage or trying it.

tmux for the worth. Boring, old technology = stable, well defined, well tested, without cognitive overload. Because life in IT is already hard enough.

Zellij does sound pretty bad.

I started to use tmux on remote machines to stop them disconnecting me when the network changes or the laptop sleeps. (Damn you systemd for breaking that, too)

Then I started multiple tmux panes remotely because it was great for dumping the long process monitoring next to the long process

Then I started using tmux panes remotely for task switching.

Then I started using tmux locally because I already knew all the keybindings and tricks.

And there are still multiple browsers, IDEs and whatnots in other windows.

At no point, the points the article touches had any relevancy. It just grew on me. So you all do whatever floats your boat, and I'll continue doung mine.

Yeah, I've also achieved a degree of Zen about things like these.

Like, I'm current on-boarding some guys onto linux workstations and linux administration, and honestly, there are many ways of holding the duck and in a lot of situations, most ways of holding the duck work equally well. I can show you two or three ways I found to work well to hold the duck, but it's still up to you to find your perfect duck rotation.

Like, I use i3 as a tiling window manager. But if I'm honest, I don't really use the tiling that much. The most tiling I tend to use is having 2-3 shells eithes stacked as dishes or one tall and a stack of dishes next to each other. Otherwise it's usually a 50/50 split of screenspace of just a full screen window. I just can't focus on more at the same time anyway. The latter use case can be had by using gnome or KDE with about the same amount of key strokes. Tmux offers it equally well, as Kitty windows do.

Personally I enjoy i3 on my workstation because a few key bindings and workflows have found their way into my lizard brain, but the newer guys relying on other window managers aren't much slower for most use cases tbh.

Similar, I've used multiplexers, terminals with such features. Currently I'm experimenting with rofi and single-purpose named kitty-terminals to easily find or launch shell environments I need. But honestly, everything works with little difference in efficiency imo.

It's more about finding something that clicks for you than doing the dogmatically correct thing. That's the wonderful thing about a linux desktop, and also it's biggest curse.

Just a side note, I think mosh is a much better tool for stopping the disconnections from network changes or laptop sleeps. It uses UDP under the hood instead of TCP so it seamlessly supports roaming (changing of IP addresses). Also brings some great performance improvements as well, especially when the remote process is dumping lots of text to standard out

After a while though, particularly on flakey connections, I end up with dozens of stale mosh sessions on each server, all listening for inbound connections that will never come.

The quickest way to clear them seems to be pkill mosh and then reconnect. It's a known bug with no anticipated fix.

Yes, mosh is great.

Except, neither RHEL nor SLES include it in the base repo. This means getting it approved and installed on servers in most enterprises is never ever going to happen.

Thus, mosh is dead to me (a poor sysadmin who lives under constant fear of The Security Team).

Good point. It also requires opening some UDP ports, which many security teams balk at. Real shame though because it makes life a lot better.

I do, because I'm a professional who needs to get work done, instead of dicking around in React all day and writing edgelord blog posts about 40-year-old tools.

This is a great example of engaging writing that fails to convey an appreciable message and even though I use tmux locally and I had a thought the other day that I should stop, I hope that the author can channel their energy toward a better formula for thoughts.

I tend to agree with this guy. I like using multiple windows or tabs in konsole and dont use tmux etc. If you're spending time sshing into remote machines tmux etc is the way to go. Although when I remote in I still don't use tmux or screen in general. I prefer using nohup for long running processes or even just keep the laptop from sleeping by plugging it in.

Arrogant and pointless? You want to use a GUI, go for it.

To me, just because most of my workflow doesn't need to change irrespective if I'm working locally or via ssh, is already making terminal multiplexer a win.

Also, there's something to be said about terminal just being a more productive way to work with computers. The constrains that a terminal puts on software used in it, make the individual pieces compose with each other way better, precisely because text composes better than graphic interfaces. (That's why "visual programming" will always suck.)

My workflow for decades now is entirely terminal with terminal multiplexer and a browser window. The graphical interface works better for exploratory work when I'm mostly navigating and consuming information, like clicking around the web, the textual interface works better for actual precise control and interaction with software. The "GUI" for me is just for changing if my browser/terminal are displayed side by side or maximized and switching between them.

From TFA: My impression is that the sole purpose of the terminal multiplexer hype train stems from a perceived sense of pseudo-elitism…

—-

Whoa there buddy. It’s fine to say: “I tried a thing, and it just wasn’t for me”.

But to proceed from that point and onto: “so rather just letting things be, or making a good-faith effort to understand those with differing opinions, I’m going to project and harshly judge them” is such a downer.

I guess what I’m trying to say is, I tried reading this blog and it just wasn’t for me.

Lmao yeah, a hype train that began in checks notes 1987 when screen was released.

These children have zero knowledge of history or the craft itself, and I wish we could take away their computers.

He's right though. Same for people who use TUI editors. Let's just call a spade a spade.

Heh. I still remember when we made fun of people for not being able to hack it on the terminal (and we were all still using screen back then to be productive). Tech is such an irrational pop culture. Nobody has respect for history, and anything old is automatically labeled elitist. Where did we go wrong?

He's not right. There's a whole host of features and functionality that terminal multiplexers bring to the table that he doesn't even begin to address. For such a long article it's actually quite shallow.

I mean, if I'm having fun and I'm productive, why do I have to justify my setup? But if I would, I'd say that VSCode didn't support all of the Vim functionality, so I started using NeoVim and to avoid managing multiple terminal windows I use tmux.

>why do I have to justify my setup?

Precisely. I just wasted all that time to read through that long opinion piece, only to shrug and think "to each their own."

Feels like it's totally missing the point of why tmux is used on desktop and in a very arrogant tone.

Windows manager saves layouts. I want to save both layout and states. I want to be able to quickly switch from one project workspace to another, without having to use ctrl+z and fg or creating term windows everytime.

Also, a lot of people use one workspace for one app on their WM (1 for terminal, 1 for browser, etc...) I like that my terminal has its own workspace, so I don't have to pollute the workspaces of my WM with tons of different terminal windows.

Maybe spend more time understanding the problem that is trying to be solved before writing a long ass arrogant article?

Another great example of the eternal question, where the indirection go? Note that when browser tabs were invented this same debate happened.

+1. I think that about summarises it.

Window managers can plausibly already do a lot of what other software can do, yet in practice, popular workflows tend to assume very little from the window manager.

I try to avoid terminal multiplexers in favour of Sway/Emacs/dtach/SSH multiplexing, but I still often reach for tmux.

Now I have terminal tabs in my IDE and can mix and split with code in all sorts of ways

I use screen all the time in an SSH session. Locally, not so much.

Although if I'm running something that I know will take hours, I tend to run that in Screen because I'm likely to nuke the terminal by accident.

"Nuking the terminal by accident" is a serious thing for me; I do it all the time, though usually it is not a big deal. I have way too many terminal windows open because I do all sorts of chaotic nonsense and my "open terminal" shortcut is too convenient.

What I really need, however, is a simple shortcut that yanks the terminal window from wherever it is, puts it in the current workspace and focuses on it. I keep postponing making it, it should be simple with xorg tools (can you do that in Wayland?).

I use Guake for this. I have it configured to fire up Tmux and then I have it bound to Ctrl Alt T, and it drops down a terminal anywhere I am: any desktop, any screen. I didn't read the entire article (I don't think it's particularly well-written or stems from any particular expertise in the domain), but I doubt the author addresses the huge advantage I see with terminal multiplexers, which is it allows me to cut and paste from the terminal without using a mouse, and allows me to log scroll back and capture sessions effectively in any terminal emulator I use, not just a fancy one like iTerm2.

This sounds like a great use case for tmux. Have one (1) terminal open, and as many panes/tabs/whatever as you need.

Came here for `nohup`. Learned about `disown` and `reptyr`. Nah, I'll just use `screen`.

Reply on news.ycombinator.com