You Don't Need a Terminal Multiplexer on Your Desktop(xn--gckvb8fzb.com) |
You Don't Need a Terminal Multiplexer on Your Desktop(xn--gckvb8fzb.com) |
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>.
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.
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 -SIf 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 (:
Source: this is a description of my own workflow and preferences, so I’m the ultimate authority on the subject, haha.
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.
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.
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.
—-
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.
These children have zero knowledge of history or the craft itself, and I wish we could take away their computers.
Precisely. I just wasted all that time to read through that long opinion piece, only to shrug and think "to each their own."
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?
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.
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.
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?).
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.
The quickest way to clear them seems to be pkill mosh and then reconnect. It's a known bug with no anticipated fix.
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).
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.
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.