4 ms·

To throw gasoline on the fire: this how I’ve always felt about tmux. Why use an incomplete in terminal windowing system when I can just have multiple terminal w

To throw gasoline on the fire: this how I’ve always felt about tmux. Why use an incomplete in terminal windowing system when I can just have multiple terminal windows open managed by the superior OS window system. (That said I know tmux is sometimes the only option and then it makes sense to me)

kurisufag 1y ago
tmux (and screen) are incredible assets for remote sessions, both for continuity across dropped shells and multi-shell activities when the connection process is tedious (multiple jumphosts, proxies, etc.)
- o11c 1y ago
  The continuity benefit is much less than it used to be, now that we have systemd with `enable-linger` so we can make proper daemons.
  - em-bee 1y ago
    that's not what tmux provides continuity for. the continuity is for interactive sessions. on my server i have more than 20 tmux windows, each one for one specific purpose. they have been running for several years.
    - o11c 1y ago
      My point is that a lot of hysterical-raisin interactive sessions really don't need to be.
- jauntywundrkind 1y ago
  I've fallen out of using it, but for a while I was using dtach to do similar without the virtual terminal multiplexing. Much much more direct. I'd just run a vim session. If I needed terminals, they were in my vim! Even wrote a short shell-script to automate creating or re-attaching to a project specific vim session. https://github.com/jauntywunderkind/dtachment https://github.com/jauntywunderkind/dtachment Haven't looked into it, but I'm love a deeper nvim + atuin (shell history) integration.
  - iiyama 1y ago
    It might be quite similar window/tab managing functionality, but for me it's the same thing that made me choose tmux over screen: it comes with a nice status bar as default and hotkeys are somehow easier to memorize.
    - jauntywundrkind 1y ago
      My dtach+nvim uses nvim as terminal multiplexer & "status bar", which is pretty ok! Dtach only serves as a very very dumb pass through (where-as tmux really is a persistent virtual terminal that clients can read-out from).
em-bee 1y ago
because the OS window manager isn't superior. i have two dozen tmux windows in half a dozen sessions locally. i have shortcut keys to switch between sessions and between windows. i can do that while mixing the terminal with other gui apps. i have yet to find a window manager that lets me group so many terminals into sessions all on the same workspace.
- jolmg 1y ago
  > i have two dozen tmux windows in half a dozen sessions locally. > i have yet to find a window manager that lets me group so many terminals into sessions all on the same workspace. Locally-speaking, I don't really see the point of mixing tmux sessions and tmux windows. I wonder if you mean "sessions" -> tmux windows and "windows" -> tmux panes. What about i3/sway? You can have a tabbed container (functions like tmux windows) with split containers inside (functions like tmux panes). You can even float the tabbed container with all windows organized inside.
  - em-bee 1y ago
    I don't really see the point of mixing tmux sessions and tmux windows. sessions let you group windows. i have a group/session for each project/purpose. one session is for all remote connections. one for my personal stuff, diary, etc. one for my hobby. one for personal dev projects, one for client work. sessions also means that i can connect to tmux from multiple terminal windows. i generally have two windows, one for dev work and one for everything else. generally i feel that having more than half a dozen windows in a session makes the session unwieldy, harder to navigate, because it becomes more difficult to find the window i am looking for. which would be the same problem if each was a gui window. try to find your way around 20 gui windows.
    - codethief 1y ago
      > one session is for all remote connections. one for my personal stuff, diary, etc. one for my hobby. one for personal dev projects, one for client work. Why would you have all those open at the same time, though? Isn't that incredibly distracting? (Disclaimer: I have no experience with tmux to speak of, beyond briefly trying it once or twice.)
MobiusHorizons 1y ago
I would typically not bother with tmux unless ssh is involved.
cturner 1y ago
I tend to run my tmux session for months at a time on my office workstation. When I remote in to that computer, I can type ‘tmux attach’ and all my context is there. I might have four long arc dev projects running at once, and my planning system, all within those windows. On our datacentre servers, I also have tmux running. It is fast to connect to these hosts, attach tmux and continue from where I left off. Another use case: it is common for corporates to require devs to use windows desktops, but to then give them a headless linux host in a datacentre for development work. Here, you use putty to connect to the linux host, fullscreen it, run tmux. On your desktop you have outlook and office and putty and a browser and no dev tools. You can do all your planning and dev work on the linux host, using your favourite ten thousand hours text editor and building your own tools, and this becomes your hub. You lose awareness that you are connected to this from a locked down windows host. Corporate security reboots your windows host for patching several nights in a row, and it does not cause you any hassle because your work context is in the tmux session on another host.
deleted 1y ago
[deleted]
Twey 1y ago
The difference is that tmux, with all its state, typically runs on a remote system. The graphical equivalent would be a VNC &c. session, assuming that the remote machine has the prerequisites for that (which is a pretty big ask).

kurisufag 1y ago

tmux (and screen) are incredible assets for remote sessions, both for continuity across dropped shells and multi-shell activities when the connection process is tedious (multiple jumphosts, proxies, etc.)

o11c 1y ago
The continuity benefit is much less than it used to be, now that we have systemd with `enable-linger` so we can make proper daemons.
- em-bee 1y ago
  that's not what tmux provides continuity for. the continuity is for interactive sessions. on my server i have more than 20 tmux windows, each one for one specific purpose. they have been running for several years.
  - o11c 1y ago
    My point is that a lot of hysterical-raisin interactive sessions really don't need to be.
jauntywundrkind 1y ago
I've fallen out of using it, but for a while I was using dtach to do similar without the virtual terminal multiplexing. Much much more direct. I'd just run a vim session. If I needed terminals, they were in my vim! Even wrote a short shell-script to automate creating or re-attaching to a project specific vim session. https://github.com/jauntywunderkind/dtachment https://github.com/jauntywunderkind/dtachment Haven't looked into it, but I'm love a deeper nvim + atuin (shell history) integration.
- iiyama 1y ago
  It might be quite similar window/tab managing functionality, but for me it's the same thing that made me choose tmux over screen: it comes with a nice status bar as default and hotkeys are somehow easier to memorize.
  - jauntywundrkind 1y ago
    My dtach+nvim uses nvim as terminal multiplexer & "status bar", which is pretty ok! Dtach only serves as a very very dumb pass through (where-as tmux really is a persistent virtual terminal that clients can read-out from).

em-bee 1y ago

because the OS window manager isn't superior. i have two dozen tmux windows in half a dozen sessions locally. i have shortcut keys to switch between sessions and between windows. i can do that while mixing the terminal with other gui apps. i have yet to find a window manager that lets me group so many terminals into sessions all on the same workspace.

jolmg 1y ago
> i have two dozen tmux windows in half a dozen sessions locally. > i have yet to find a window manager that lets me group so many terminals into sessions all on the same workspace. Locally-speaking, I don't really see the point of mixing tmux sessions and tmux windows. I wonder if you mean "sessions" -> tmux windows and "windows" -> tmux panes. What about i3/sway? You can have a tabbed container (functions like tmux windows) with split containers inside (functions like tmux panes). You can even float the tabbed container with all windows organized inside.
- em-bee 1y ago
  I don't really see the point of mixing tmux sessions and tmux windows. sessions let you group windows. i have a group/session for each project/purpose. one session is for all remote connections. one for my personal stuff, diary, etc. one for my hobby. one for personal dev projects, one for client work. sessions also means that i can connect to tmux from multiple terminal windows. i generally have two windows, one for dev work and one for everything else. generally i feel that having more than half a dozen windows in a session makes the session unwieldy, harder to navigate, because it becomes more difficult to find the window i am looking for. which would be the same problem if each was a gui window. try to find your way around 20 gui windows.
  - codethief 1y ago
    > one session is for all remote connections. one for my personal stuff, diary, etc. one for my hobby. one for personal dev projects, one for client work. Why would you have all those open at the same time, though? Isn't that incredibly distracting? (Disclaimer: I have no experience with tmux to speak of, beyond briefly trying it once or twice.)

MobiusHorizons 1y ago

I would typically not bother with tmux unless ssh is involved.

cturner 1y ago

I tend to run my tmux session for months at a time on my office workstation. When I remote in to that computer, I can type ‘tmux attach’ and all my context is there. I might have four long arc dev projects running at once, and my planning system, all within those windows. On our datacentre servers, I also have tmux running. It is fast to connect to these hosts, attach tmux and continue from where I left off. Another use case: it is common for corporates to require devs to use windows desktops, but to then give them a headless linux host in a datacentre for development work. Here, you use putty to connect to the linux host, fullscreen it, run tmux. On your desktop you have outlook and office and putty and a browser and no dev tools. You can do all your planning and dev work on the linux host, using your favourite ten thousand hours text editor and building your own tools, and this becomes your hub. You lose awareness that you are connected to this from a locked down windows host. Corporate security reboots your windows host for patching several nights in a row, and it does not cause you any hassle because your work context is in the tmux session on another host.

deleted 1y ago

[deleted]

Twey 1y ago

The difference is that tmux, with all its state, typically runs on a remote system. The graphical equivalent would be a VNC &c. session, assuming that the remote machine has the prerequisites for that (which is a pretty big ask).