[HN Gopher] Tmux is worse-is-better
___________________________________________________________________
Tmux is worse-is-better
Author : hiAndrewQuinn
Score : 162 points
Date : 2024-05-25 17:20 UTC (5 hours ago)
(HTM) web link (hiandrewquinn.github.io)
(TXT) w3m dump (hiandrewquinn.github.io)
| neilv wrote:
| Basic `screen` or `tmux` awareness (how to start it, how to
| create and switch between windows, how to reattach if
| disconnected) should be in the toolkit of anyone who finds
| themself needing to SSH into a server.
|
| Especially in startups, where you can't afford to be sitting atop
| massive too-big-to-fail enterprise bureaucracy, and need to
| understand the systems, and work creatively and efficiently with
| them.
| noloblo wrote:
| i use neovim and screen as defaults and find them quite useful,
| but never found tmux useful, please change my mind tmux what
| are good starter tutorials?
| SoftTalker wrote:
| screen and tmux are similar. Unless you need some of the more
| obscure features, they mostly do the same things. Screen can
| attach to a serial port, not sure tmux can (but you can use
| 'cu' or another utility for that in a tmux window).
| Graziano_M wrote:
| Tmux lets you make a pane toggle full screen. That's reason
| enough for me.
| mh-cx wrote:
| As tmux can be extended with plugins I'd recommend to check
| through this list and see if you find something useful:
|
| https://github.com/tmux-plugins/list
|
| As a neovim user I can also very much recommend this vim
| plugin to seamlessly navigate between tmux panes and neovim
| windows:
|
| https://github.com/christoomey/vim-tmux-navigator
| nurple wrote:
| This is a killer feature IMO. Bind the ctrl-hjkl in
| vim/neovim for navigation and go between vim panes and tmux
| panes transparently, beautiful.
|
| ETA:
|
| My tmux config for vim-tmux-navigator: https://github.com/j
| oshperry/mynix/blob/master/users/josh/co...
|
| My nix home-manager config references that: https://github.
| com/joshperry/mynix/blob/master/users/josh/de...
|
| And adds the plugin: https://github.com/joshperry/mynix/blo
| b/master/users/josh/de...
| devsda wrote:
| In screen, splits and windows behave more like vim buffers
| and splits. That works nice for an editor because I might
| want to look at the same file at two different locations. I
| find it weird to apply that concept to shells.
|
| Tmux panes and windows behave more like separate shells. It's
| similar to what we get with individual shell gui windows that
| are neatly stacked and makes it easy to follow.
|
| I don't know if there is an equivalent in screen, but I like
| and heavily use the zoom feature which can temporarily
| minimize other splits and focus on single shell.
| kzrdude wrote:
| Tmux does the same job as screen.
|
| I didn't want to before, but now in the current year I
| switched from gnu screen to tmux, keeping the key bindings
| the same. Ending a 15 year or so streak.
|
| The reason is that tmux supports more modern features like
| hyperlinks and truecolor, in the distro versions. Once
| settled, I don't notice a difference.
| sshine wrote:
| How does tmux support hyperlinks?
|
| My virtual terminal (iTerm2, Alacritty) makes mouse-
| clicking a link opens it in Firefox.
|
| I've used GNU screen for 25 years. I gave tmux a try 10-15
| years ago, but I didn't see the upside.
|
| I'm curious about Zellij and its wasm plugins, but equally
| skeptical.
|
| All I ever do in screen is ^A D, ^A C, ^A SPC, not sure
| what else I need?
| CoastalCoder wrote:
| IIRC, iTerm2 has special support for tmux. E.g., tmux panes
| get corresponding iTerm2 panes?
| lelanthran wrote:
| > i use neovim and screen as defaults and find them quite
| useful, but never found tmux useful
|
| Thank heavens there's someone else - I thought I was the only
| one[1].
|
| [1] I use screen, and then use vim with multiple splits and
| tabs, with each buffer being a `:terminal`. Works very for
| me, because I get all the terminals I want, splitted and
| tabbed in any fashion I want, using my existing vim muscle
| memory to switch between them, minimise, maximise, etc. Also,
| takes about 1s to save the session if I ever feel the need to
| exit vim (I never do, though).
| skydhash wrote:
| I started with screen and then move to tmux (don't really
| remember why). I've never been a fan of :terminal. I start
| and quit Vim multiple times a day (even for the same
| project) and opening new tmux pane or tab is the reflex for
| me. I rarely use tabs in vim. My philosophy is that buffers
| are like sheets of paper on my desk. I rearrange them based
| on what I want to do. Moving to another tab is like moving
| to another desk. If I need the terminal for a quick
| command, I do Ctrl-Z.
| Izkata wrote:
| I've only used tiling window managers for over a decade, so
| for me screen is only for detaching, vim usually only one
| file at a time, and the window manager lets me tile/stack
| those and the web browser, zoom, etc.
| SoftTalker wrote:
| Yes very much. You don't need to be an expert. Just knowing how
| to detach from a running tmux and reattach later, and knowing
| how to create and navigate between tmux windows and panes is
| most of what you need to know.
| ProfessorZoom wrote:
| bad for energy? sir i code typescript in tmux
| kshmir wrote:
| You'll need gpu acceleration
| echelon wrote:
| It figures that a fancy terminal emulator developer would take
| issue with tmux.
|
| Tmux undoes all the fancy performance end ergonomic stuff they
| spent their time and energy developing. Moving stuff to the
| GPU, multithreading, etc. -- all just to call tmux anyway and
| lose 100% of those features!
|
| What we really need is a protocol for tmux (or other terminal
| multiplexers) to expose its internal state to native terminal
| emulators so that you can get the best of both worlds. That's a
| tremendous amount of work, though.
| lexlash wrote:
| Like `tmux -CC` and iTerm2?
|
| https://iterm2.com/documentation-tmux-integration.html
| dymk wrote:
| as far as I'm aware, there is some sort of protocol for
| looking at tmux state. iTerm has tmux integration, and will
| show tabs/splits as native (sub)windows.
|
| https://iterm2.com/documentation-tmux-integration.html
|
| https://github.com/tmux/tmux/wiki/Control-Mode
|
| The downside is it doesn't work very well. Tmux tabs open as
| new iTerm windows instead of tabs, there are resizing bugs,
| etc.
| SoftTalker wrote:
| Love tmux. I don't find myself splitting one window into panes
| very often, but I certainly use multiple "tabs" (windows) in a
| tmux session. I keep a tmux session running on my work computer,
| which has logins to all my commonly needed systems. I can ssh in
| from home (or anywhere), attach to that tmux session, and
| instantly have everything I need.
| noloblo wrote:
| how do you attach to a tmux session via ssh?
| n_jd wrote:
| You SSH in and run `tmux attach`
| praptak wrote:
| ssh -t -A yourhost.com "tmux attach -d"
| CaptainOfCoit wrote:
| Other answers tell you how to attach, but vital missing piece
| is that beforehand, don't "quit"/"exit" the session but
| "detach" from it instead, so you can attach later. By default
| the command is $PREFIX + D
| j2kun wrote:
| > remote persistence
|
| This is the real reason I actually need tmux. I often lose
| connection to a server for various reasons and don't want to lose
| my vim session or whatever
| adtac wrote:
| tmux over mosh over wireguard is all you need
| blueflow wrote:
| why the wireguard step?
| adtac wrote:
| everything works fine with just tmux + mosh, but I like to
| bind sshd on the wireguard interface so that there aren't
| any listening ports accessible from the public internet
| blueflow wrote:
| ... except for the UDP port where wireguard receives its
| pakets.
| pessimizer wrote:
| I've literally had projects running from screen sessions for
| years. I always assumed the purpose of them was so I could turn
| off my computer while doing something over the network that was
| either long-lived, on an unstable connection, or a
| daemon/server of some sort.
| e40 wrote:
| I can't live without X11 emacs, so I use Starnet's FastX, which
| allows me to disconnect and reconnect either when my connection
| drops or when I move between office and home. I absolutely
| couldn't live without it.
| bradfox2 wrote:
| Is there anything better than tmux for this purpose? I need
| persistence but hate the key bindings and general interface.
| timdev2 wrote:
| My use-cases are pretty basic, and my use isn't all that
| frequent, but I've been very happy with: https://zellij.dev/
| johnchristopher wrote:
| There's still `screen` ? Also, I think tmux keys can be
| rebinded ?
| schainks wrote:
| Byobu is equivalent, different hotkeys:
| https://www.byobu.org/
|
| I have moved between tmux, byobu, and screen at various times
| in my career. I wouldn't say one is better than the other, as
| they all do the job I need just fine (eg persistent session
| state on remote machines)
| mananaysiempre wrote:
| Dtach[1] does session persistence and nothing else--it leaves
| refreshing the screen to the program running inside it (it
| can send a ^L or a SIGWINCH upon reattaching but that's it).
|
| [1] https://dtach.sourceforge.net/
| simonmic wrote:
| +1 for dtach. That plus mosh and emacs works extremely well
| with no fuss.
| yjftsjthsd-h wrote:
| Depending on exactly what you mean by persistence, there's
| always mosh.
| shadowgovt wrote:
| I just use emacs. When my terminal drops, I just `emacsclient
| -t` and I'm back to work.
| vaylian wrote:
| Sounds like you might like Zellij: https://zellij.dev/
| wpietri wrote:
| Could you say more about this? I took a look at this page
| and it seems to be mainly about having a window manager in
| a terminal: https://zellij.dev/about/
|
| But I have a window manager, so all I ever want out of
| something like screen or tmux is a persistent remote
| session that survives network issues or me closing my
| laptop for a bit. Is that something that Zellij is better
| at?
| cosmojg wrote:
| In my experience? Yeah, Zellij's UX for session
| management vastly improves over that of screen and tmux,
| and it comes out of the box with much saner defaults.
| However, like tmux, it offers more than just session
| management, and also like tmux, it does it all while
| remaining rather small and performant.
|
| Just try it and see if you like it. I've found that most
| of things I didn't like, mainly the default TUI borders
| and buttons, were far more easily reconfigured compared
| to tmux.
| rochak wrote:
| What about scriptability? Is Zellij as hackable as Tmux
| to create different plugins?
| alex_smart wrote:
| On mac, iterm2 has excellent tmux integration. You start tmux
| in control mode (tmux -CC) and it opens a new window for that
| session with all the multiplexing handled by the terminal
| instead. You get to use all of your normal terminal keyboard
| shortcuts and terminal interface.
|
| It is the best of both worlds. And, yes, of course it works
| with a remote ssh session.
| pwg wrote:
| Does tmux allow redefining the key bindings?
|
| GNU screen allows for redefining (at least) its hotkey. If
| tmux allows the same maybe you could redo the bindings more
| to your liking?
| qup wrote:
| yes, it does.
|
| I love tmux and hate the default hotkey
| dahart wrote:
| Yes you can define your own key bindings. The default is
| the same "prefix key" that 'screen' uses - Ctrl-b.
| Personally I like to use Ctrl-j because it's easier to type
| and has fewer conflicts with shells and other things. Most
| of the key bindings that follow the prefix key seem natural
| to me, stuff like 'c' to create a new tab, 'd' to detach
| from tmux, 'n' to go to the next tab, etc., but all of that
| can be customized.
| orhmeh09 wrote:
| You can even use a sequence to activate it -- my prefix
| is "typing ` twice within x ms" and it avoids conflict.
| jasomill wrote:
| In screen, I just use a single backtick, as I very rarely
| use it for any other application in a terminal session (I
| prefer "$()" in shell, invariably edit TeX and Lisp in
| GUI Emacs, and the only only other thing that comes
| immediately to mind is opening the developer console in
| mpv and various video games).
| zimpenfish wrote:
| > The default is the same "prefix key" that 'screen' uses
| - Ctrl-b.
|
| Isn't the default command key ctrl-A for screen? Which is
| why I've always had to change it (to ctrl-O which is much
| more sensible) because I can't live without ctrl-A in the
| terminal etc.
| atsaloli wrote:
| Yep. You can run tmux inside screen. Ctrl-A for screen,
| Ctrl-B for tmux. (Of course, you can redefine the command
| key in both screen and tmux.)
| dahart wrote:
| You're right! Thanks, yeah I can't live without ctrl-a
| either, I use that all the time.
| anthk wrote:
| Yes, I use C-z instead of C-b
| bayindirh wrote:
| It's not only a safety net for losing connection. As soon as I
| connect to a server to do work, I automatically fire screen,
| and create new terminals and rename them as I work with the
| system.
|
| If my work is unfinished, I leave the screen as is, and
| disconnect. We don't touch each others' screen instances on
| servers, so it's a safe workspace which I can return whenever I
| want.
| marcosdumay wrote:
| Nowadays everybody is in a GUI terminal emulation anyway.
| Multiplexing is completely redundant.
|
| I imagine everybody uses screen and tmux mainly for remote
| persistence.
| amouat wrote:
| Just wanted to say that I appreciate how well written this is. It
| does make a difference when an author can clearly and succinctly
| state their case.
| hiAndrewQuinn wrote:
| Thanks!
| PUSH_AX wrote:
| I would be lost without tmux, if you have a regular ssh date with
| some machine it's a life saver.
| jrockway wrote:
| I agree with all of this completely. I also run Windows as my
| host OS and do all my work in Linux. I don't use X, I ssh into
| the Linux VM and have Emacs alongside a bunch of shells running
| in tmux. It is very productive and even when I have a physical
| Linux machine, I just start up X, maximize a terminal, and use
| tmux.
|
| The author of Kitty is also right about performance. I've never
| looked into exactly where the problem is, but tmux <- ssh <-
| windows terminal is very very very slow. This is most annoying
| when some program starts printing a ton of stuff and your control
| C keypress is ignored for a good 15 seconds. While this Should
| Not Be, I can live with it for the other gains. I do a lot of
| pair programming with people, and I've never seen a better or
| more productive setup than this one.
| bombela wrote:
| What is the advantage/use of Windows compared to some Linux
| desktop in your setup?
| hiAndrewQuinn wrote:
| OP here: Keeps me corporate-friendly, mostly. Half my life is
| lived in the terminal and the other half is lived in the
| Microsoft Office suite, and the second half is what really
| pays the bills for now. C'est la vie.
| jrockway wrote:
| For me it's because I game and don't want:
|
| a) 2 separate machines
|
| b) To get banned for running the games in a Windows VM
|
| Work is a Microsoft place, but honestly the web version of
| Outlook works great under Linux. Teams is usable. (My Linux
| friends complain that it sucks, but what they don't know is
| that it also sucks on Windows!)
| skydhash wrote:
| I do the macOS/Linux VM combo. It's mostly that macOS is good
| for standard use. The hardware is nice, the apps are useful,
| etc. My VM is for development purpose. It's Debian and I3. I
| can have a VM for each project and I can suspend them when
| switching. Due to complexity of software projects and tooling
| conflicts, it's better to keep each project in its own space.
| I'd do the same if I was on Linux Desktop.
| tedunangst wrote:
| Possibly tmux buffering output. Control C kills the process
| immediately, but there's still 15 seconds of output in the
| pipe.
| jrockway wrote:
| You motivated me to look into this more. I wrote a program
| that just floods stdout and prints what time it got SIGINT
| and then exits. Of course this program exits immediately when
| you press C-c.
|
| The program that I have the most trouble with is jlog
| (https://github.com/jrockway/json-logs). I wrote it so this
| could very easily be my fault. (I think it's the colors and
| whatnot, which I have not explored yet.)
| orev wrote:
| That 15 second lag is related to the network buffering, and
| would happen inside a muxer as well as outside. A muxer may add
| another layer of buffering, but I find that you can typically
| clear it out faster by switching to another window then back,
| so the output doesn't need to be sent over the network.
| jrockway wrote:
| That's a very good point. There is the entire Linux network
| stack in the way, and the Hyper-V virtual network driver, and
| the Windows networking stack.
|
| In like 2008 I was using a Perl library that was all about
| zero-copy networking. That is not what this is.
| kelnos wrote:
| I feel like "parsing each keystroke twice" is pretty low on the
| list of things that wastes CPU cycles and drains my laptop
| battery. I cannot at all get worked up over this, getting to the
| point I'd pull out the word "poison" to describe it.
|
| It's nice that Kitty does most of what tmux does built in, but as
| the author points out, that's not really all that helpful for
| anyone who does any work over ssh.
|
| And to me, bundling all that into a terminal emulator is bloat.
| Terminals should be terminals. If I want a multiplexer on top of
| that, I will... use a multiplexer on top of that.
|
| I am potentially sympathetic to the idea that tmux and screen
| make it harder for terminal developers to add new features to
| their terminals. I don't really know enough about the issues
| involved to form an opinion. But from the perspective of a
| regular user, I do not want a multiplexer in my terminal app.
| When I need one, I prefer to reach for an app-agnostic
| multiplexer like tmux or screen.
| colordrops wrote:
| Agree with all your points.
|
| The main problem with Tmux that no one talks about is its
| arcane configuration and interaction patterns. If you set up a
| ton of config while gritting your teeth, it begins to work
| well, but the configuration semantics are a nightmare. I would
| love something similar to tmux that has sane configuration and
| theming. I switched from XMonad to i3 for the same reason.
| usrbinbash wrote:
| Sure, but how often do you need to touch that config?
|
| Since I keep my configs in a repo, I just checked the last
| time I changed my `.tmux.conf`. Turns out it was 2018, and I
| changed a grand total of 2 lines. And I use tmux daily, not
| just remote, but also on my local machine.
|
| So yeah, if I am using something for more than half a decade
| without requiring any change, then its pretty safe to say
| that whatever hassles the configuration of that something
| imposes, is completely irrelevant.
| kergonath wrote:
| > Sure, but how often do you need to touch that config?
|
| It's not only the config, though. It's the arcane shortcuts
| and the weird way it seems to handle most things (trying to
| get the mouse working is a bloody nightmare and it
| regularly borks the terminal). I have a mouse with a
| scrolling wheel, for example. It works fine with most
| programs over ssh, why is it such a pain with tmux? Such
| pains remain even after having felt down the rabbit hole
| and spent 2 weeks tweaking settings.
|
| iTerm2 is fantastic and I would be very happy to just use
| it and call the problem solved, but I don't have a Mac at
| work.
| skydhash wrote:
| > _trying to get the mouse working is a bloody nightmare
| and it regularly borks the terminal_
|
| It's literally one line of config.
|
| > It's the arcane shortcuts and the weird way it seems to
| handle most things
|
| Tmux is a TUI and the shell and other software running on
| it are themselves TUI. There will be conflict and the
| prefix solution is actually simple. Tmux solves one
| particular problem and solves it well. It's on you if you
| want it to be something else.
| sigil wrote:
| > Sure, but how often do you need to touch that config?
|
| More often than I'd like! tmux config has broken backwards
| compatibility on me multiple times over the years.
|
| This is fine for most software -- you upgrade your config
| once and you're done. However, the nature of tmux is that I
| use it on many servers, some old and some new, some with
| tmux 1.x and some with 2.x. Getting a ~/.tmux.conf from my
| dotfiles repo that works across both has been papercutty.
|
| Love tmux though & can't imagine tty life without it -- I
| run it locally as well as on remote machines.
| fl0ki wrote:
| It's interesting we've had such opposite experiences with
| tmux configuration.
|
| My home git log shows my first tmux configuration was in
| 2017. Since then, several options have been removed, they
| now throw an error on startup, and mess with muscle memory
| for key bindings that are essential to using a program like
| this.
|
| This means that to get tmux working properly again I have
| to catch up on years of release notes to figure out what
| I'm supposed to change. I have never once had to do this
| with screen despite using it for over 20 years.
|
| Any time my muscle memory is betrayed, I give up and go
| back to screen and don't bother touching tmux again for
| several months.
| amluto wrote:
| I'm one of the people who _much_ prefers tmux's "session
| groups" over its "sessions". Alas, as far as I know, it's
| entirely impossible to configure tmux to get session groups
| by default: it's a command line option, not a configuration
| option.
| em-bee wrote:
| i am running half a dozen tmux sessions without any
| configuration at all, and a few more where the only
| configuration is to change the key for tmux commands away
| from ctrl-b. i used to have several more of those, but i am
| no longer nesting tmux sessions as much.
| yoyohello13 wrote:
| Look into zellij
| pzmarzly wrote:
| From the perspective of "a regular user" (which is a bad term,
| because of course I see myself as the norm), I don't care if
| multiplexer is part of terminal app or not, but I do care about
| it reacting to my clicks. I don't want to learn obscure multi-
| step keyboard shortcuts in order to open a new tab, rename a
| tab, resize a pane, reorder tabs, copy the scrollback buffer,
| etc.
|
| Sadly, that seems to leave me with only 2 options that work
| well over SSH:
|
| - using a terminal with client-server model and built-in
| multiplexer (VSCode Remote SSH extension, WezTerm)
|
| - using iTerm2 with tmux integration (apparently nothing else
| implements tmux control protocol
| https://unix.stackexchange.com/a/280829)
| Barrin92 wrote:
| you might want to give Zellij a try. (https://zellij.dev/)
| Works like tmux but with the UI friendliness of more modern
| apps.
| pzmarzly wrote:
| Okay, just going through the first tutorial[0], I am
| convinced that Zellij is truly something else. I've never
| opened up my wallet[1] so quickly for any open-source
| project, but here the author is clearly creating something
| amazing (and maintaining awesome documentation and
| tutorials!). Thank you a lot for this recommendation :D
|
| BTW this is the first time I've seen a working drag and
| drop TUI (you can use drag-and-drop to move floating panes
| around).
|
| [0] https://zellij.dev/tutorials/basic-functionality/ [1]
| https://github.com/sponsors/imsnif
| skitter wrote:
| Maybe it's because I don't use it that intensely, but
| I've found the default a bit noisy, so I switched my
| default layout to only contain `pane` and turned pane
| frames off.
| Izkata wrote:
| Reminds me a bit of twin: https://github.com/cosmos72/twin
|
| I found out about it from this blog post nearly two decades
| ago: http://web.archive.org/web/20190120170204/http://www.t
| ermina...
| bayindirh wrote:
| > I am potentially sympathetic to the idea that tmux and screen
| make it harder for terminal developers to add new features to
| their terminals.
|
| Both are actively maintained and can work with modern
| terminals, as long as the hosting terminal is standards
| compliant.
|
| I don't understand why people love to break standards.
| fiddlerwoaroof wrote:
| The cynical view is that non-standard features make your
| product sticky
| bayindirh wrote:
| So EEE is preferred now?
| rickstanley wrote:
| Fully agreed.
|
| I myself use 2 terminals: Alacritty and WezTerm. The former for
| local work, and the latter for my VMs, and occasional remote
| server work.
|
| I couldn't explain exactly why I use separated applications,
| since WezTerm works well for local (which even has a menu entry
| for that) and remote alike, but I'm comfortable with the
| workflow that I have today, and for me it's enough and what
| matters.
| fiddlerwoaroof wrote:
| I like how iTerm2 can act as a UI for tmux via tmux's control
| protocol. We don't need to reinvent tmux to fix some of the UX
| issues of tmux sessions inside terminal tabs inside terminal
| windows.
| Xeamek wrote:
| >that's not really all that helpful for anyone who does any
| work over ssh.
|
| If you are hoping to new machines every time then sure.
|
| But lets be honest, thats a minority.
|
| I don't know kitty in specific, but wezterm ie. can connect to
| target via SSH, start daemon of itself there and actually work
| better then tmux, because it's controlled from the client
| (where the gui runs), but with all the tmux upsides.
|
| And yes, it's not as portable as tmux (simply because its not
| as popular), but again, in majority of the situations the setup
| required is really not that much. Especially if you would spend
| that time on tmux config anyway.
| sweeter wrote:
| Kitty does this as well. They have a section on ssh-
| integration on the wiki. I personally love it. I can use the
| kitty multiplexer remotely and I can copy and paste from
| local to remote. So at least he does implement a
| solution/alternative.
|
| The thing I like about tmux and zellij is persistence and the
| "task-runner" nature of them. Its great for managing sessions
| and running things in the background. Though I do hate how
| they also break a lot of features that I do like about
| terminals.
| em-bee wrote:
| all of the tmux upsides? including detach and reattach to a
| running session? i'd love a nice gui for tabs, but i really
| use tmux for its ability to survive gui crashes locally and
| network disconnects when running remotely.
| Xeamek wrote:
| As I said, on connections it's spawns a daemon on target
| machine that will do exactly that - keeping the State
| despite clients disconnection
| scoodah wrote:
| > I cannot at all get worked up over this, getting to the point
| I'd pull out the word "poison" to describe it.
|
| Kovid Goyal has a history of being incredibly opinionated to
| the point of being combative and toxic at times. He makes some
| great software, I'm a user of kitty, but this hyperbolic tone
| about this issue is not shocking to me at all.
| biftek wrote:
| The argument about parsing twice doesn't seem very good to me.
| Vim and emacs are also parsing keystrokes, should we abandon
| them too?
|
| The cynic in me thinks it's more likely that because kitty
| offers tmux features he wants to lock users in to his product.
| ehPReth wrote:
| it's a foss project: http://www.9bis.net/kitty/
| https://github.com/cyd01/KiTTY
| ckolkey wrote:
| Not that KiTTY, this kitty:
| https://sw.kovidgoyal.net/kitty/
|
| But it's also foss, so, you're still right.
| jonathanrmumm wrote:
| why not just say "less is better?"
| kelnos wrote:
| Because that's not the common, generally accepted term.
| smcameron wrote:
| Because "Worse is Better" entered the lexicon circa 1991.
|
| https://en.wikipedia.org/wiki/Worse_is_better
| jonathanrmumm wrote:
| yes, why? seems like not that useful of a phrase if it needs
| an explanation with parenthesis in a wikipedia
| nicklaf wrote:
| The phrase was made famous in an influential essay[0] by
| Richard P. Gabriel, where he laments Lisp's relative
| failure to compete with Unix.
|
| In Gabriel's opinion, Unix proved to follow the more
| adaptive design strategy in certain ways (in spite of his
| involvement with and admiration for Lisp), and the phrase
| "Worse is better" is meant to capture the essence of that
| advantageous strategy (as outlined in the essay).
|
| The essay is worth reading and is a bit more elaborate than
| just saying "less is more", or "keep it simple, stupid".
|
| [0] https://dreamsongs.com/WorseIsBetter.html
| jonathanrmumm wrote:
| Ah so it's more "if it's not broken _enough_ , don't fix
| it"
| simonmic wrote:
| Read the essays, they're excellent.
| jonathanrmumm wrote:
| > it is better to start with a minimal creation and grow
| it as needed
|
| yes, this is a much better explanation than the wikipedia
| alabhyajindal wrote:
| Exactly. "Worse is better" makes zero sense.
| kzrdude wrote:
| It doesn't convey the same idea
| alabhyajindal wrote:
| What idea does "worse is better" convey to someone who hasn't
| heard of the phrase before?
| jonathanrmumm wrote:
| then someone needs to update the wikipedia
|
| > It refers to the argument that software quality does not
| necessarily increase with functionality: that there is a
| point where less functionality ("worse") is a preferable
| option ("better") in terms of practicality and usability.
| marcosdumay wrote:
| "Worse" is not "less". It's about things like non-complete
| features, non-scalable architecture, and non-fully solved
| problems.
|
| Besides, "less is better" is not a paradox.
|
| There is another famous phrase that is "less is more". But it's
| a very different one (And "less" would clearly map into "not
| worse".)
| camgunz wrote:
| "Worse is better" comes from an ancient story where the Lisp
| folks were trying to design an elaborate system for resuming
| interrupted syscalls, and the UNIX folks just returned a "we
| fucked up" error to the caller instead. People take different
| lessons from this. Personally I feel like this is one of the
| earliest software forms of YAGNI: the (lack of) severity didn't
| merit the engineering effort to "fix" it. But, OP's
| interpretation is also valid.
| neilv wrote:
| I once half-seriously leaned on the lightweight possibilities of
| reattachable SSH sessions, for a very-very simple way of
| running/monitoring/futzing a simple server process, when you
| don't need a big enterprise deployment and observability
| platform.
|
| https://www.neilvandyke.org/racket/rackonsole/
| chasil wrote:
| >every byte has to be parsed twice, once by the middleman and
| once by the terminal.
|
| The ~ (tilde) codes in OpenSSH imply that it also performs
| minimal parsing. Particularly, "(return)~." to terminate a locked
| session.
|
| The tmux program is invaluable to me when I have a long-running
| set of interactive commands, and I want them to survive a network
| disconnect.
|
| There may be valid criticisms of tmux, but wow is it good at this
| particular thing.
| KolmogorovComp wrote:
| The only annoying thing with tmux are recursive sessions. By that
| I mean when you run tmux on your laptop, then ssh to your server
| and start another tmux session there. It is suddenly confusing
| and you then have to escape commands depending on which session
| you want to interact with.
|
| I've been using screen at first remotely for those cases, but
| eventually bailed out and used my graphical multiplexer locally
| instead of tmux, or not using tmux remotely when already using it
| locally.
| ehsankia wrote:
| To me, the only annoying thing with tmux is copy/pasting across
| different setups and how inconsistent / flaky / tricky it is to
| get working.
| thanatos519 wrote:
| I use different escape keys for my local and remote sessions
| and after many years I don't get confused anymore.
| devsda wrote:
| I do the same for one-off tasks. I use ^a as the escape key
| locally and leave the remote server(s) to use the default ^b
| because I might need to login to random servers with no
| shared home or login as a common user and they often have
| restrictions on adding/changing custom dot files.
|
| If it gets too annoying, the remote session is openend in a
| new terminal tab and I temporarily remap the escape key to ^a
| on remote tmux.
| tetris11 wrote:
| This very much so. I wish there was some kind of SSH
| "passthrough" that allowed a tmux session on remote to attach
| to a tmux local.
| jwr wrote:
| I made this somewhat less confusing for myself by defining
| keyboard shortcuts in my Terminal app (MacOS) and using those
| for switching between tmux screens. E.g. command-n and
| command-p switch to next and previous locally, while shift-
| command-n and shift-command-p switch next and previous in a
| nested remote tmux session.
| mat_epice wrote:
| I have a system where I use a tmux-server config that has a
| different prefix (^O), status bar color (yellow), and location
| (top). I use that for my outer tmux session, then start default
| configs on other host systems. Works pretty well, I don't have
| any complaints.
| wging wrote:
| The way I typically handle that is via native terminal-app
| tabbing. Tab 1: local tmux session, tab 2: remote tmux session.
| (My normal workflow doesn't go beyond 2 systems, 3 in an edge
| case.) You don't need much support from the terminal to do it
| this way; it works in gnome-terminal on Linux and iTerm2 on
| Mac, and probably also macOS's built-in native terminal. You
| just need an app-level shortcut to go forward/back between
| tabs, then tmux's shortcuts for navigation within the system.
|
| (I don't use iTerm2's native tmux integration, so any poor
| interactions with that when I'm on Mac aren't a concern, and
| when I'm on Linux gnome-terminal has just as much utility for
| me.)
| mrshu wrote:
| Being a big tmux fan, I never thought it would come to
| something like this, but Zellij (https://zellij.dev/) has
| completely solved this for me. I generally run Zellij on my
| laptop and tmux on remote servers -- it's been a surprisingly
| positive experience so far.
|
| Try it out -- your tmux muscle memory (e.g. all the hotkeys you
| remember) will also work out of the box.
| wazoox wrote:
| For this reason I usually run screen locally and tmux remotely,
| that's good enough IMO.
| gitaarik wrote:
| Yeah that's why I use Kitty tabs for every single tmux session
| I run :)
| tombert wrote:
| > but its fundamental value add to any programmer who has to SSH
| into servers more than once a week is it allows you to split your
| screen up into multiple independent shells without needing a
| graphical environment at all.
|
| I actually think that value add for SSH is that people is the
| ability to allow long-running jobs to survive a disconnection. It
| can be frustrating doing something that takes multiple hours
| (like a large wget download) just to have your connection break
| about ten minutes before it's done. Even if you never use any of
| the other features you immediately benefit from that.
| ehsankia wrote:
| It just fits my mental model much better.
|
| It's close to a "remote desktop" where you connect to an
| existing "screen" and continue where you left off, vs each time
| you connect, a brand new "screen" being created, and it getting
| destroyed as soon as you disconnect. The fact that the shell
| dies as soon as you disconnect is far more problematic than
| just long running jobs.
| nephanth wrote:
| Exactly. One of my favorite things about working in tmux is
| that my editor session persists, whatever state my laptop is
| in. Out of battery? Rebooted after updating the kernel? My
| workspace stays the same
| tombert wrote:
| Yeah, I agree with that. I use tmux for pretty much
| everything, and I do use the splits and multiple screens when
| I do. In fact I do use it even when I'm working locally
| because I like the keyboard shortcuts and mouse support (and
| why I've never really cared if my text editor has a terminal
| built in).
| yaur wrote:
| Doesn't ^z and bg solve this?
| adw wrote:
| Not really - often what I'm doing is running something with a
| conditional breakpoint which will only be hit a long way into
| process lifetime (potentially nondeterministically), so I
| really do need "a session which will persist indefinitely
| including across SSH sessions".
| tombert wrote:
| Yep, if you remember to do that. What's nice about tmux is
| that this happens automatically. It requires zero additional
| mental forethought outside of typing tmux exactly once, and
| then all your jobs are safe, and you can still see them in
| the foreground.
| duskwuff wrote:
| No, it doesn't. There's no way to reattach to a process which
| was backgrounded and detached in another terminal -- once the
| parent terminal is gone, the process is stuck in the
| background. Most interactive processes will terminate
| immediately when this happens.
| akira2501 wrote:
| SIGHUP
| nephanth wrote:
| You'd also need to disown it if you want it to persist
| sessions
|
| If you just bg it, it will still die when your session
| disconnects
| bandie91 wrote:
| generally you can not bring processes to the foreground once
| you left the session. there are hacky ways to do it though:
|
| http://github.com/nelhage/reptyr
|
| http://github.com/jerome-pouiller/reredirect
|
| https://github.com/lkundrak/retty/
| eigenvalue wrote:
| I, for one, love tmux. But I hate it with the stock settings on a
| fresh machine. Having to use keyboard shortcuts to switch between
| windows is especially annoying. I have this in an ansible
| playbook I run on all new machines to set tmux up nicely (I also
| use ohmyzsh and atuin, but that's another story):
| - name: Install custom tmux configuration become: yes
| become_user: ubuntu git: repo:
| https://github.com/gpakosz/.tmux.git dest:
| /home/ubuntu/.tmux/ - name: Set up custom tmux
| configuration become: yes become_user: ubuntu
| shell: | cd /home/ubuntu/ ln -s -f
| .tmux/.tmux.conf cp .tmux/.tmux.conf.local .
| - name: Set up further tmux customizations become: yes
| become_user: ubuntu blockinfile: path:
| "/home/ubuntu/.tmux.conf.local" insertafter: "# EOF"
| block: | set-option -g default-shell $SHELL
| set -g mouse on set-option -g history-limit 25000
| set -g @plugin 'tmux-plugins/tmux-resurrect'
| tedunangst wrote:
| Some time ago I reported an energy wasting bug in tmux, and
| surprise twist, it was not the result of parsing every byte
| twice.
| bee_rider wrote:
| > Kovid Goyal, developer of the ePub powerhouse calibre and my
| current teminal emulator of choice Kitty, has gone on record a
| number of times saying he is not a fan of tmux. He has a whole
| section in his FAQ about it:
|
| >> [T]erminal multiplexers are a bad idea, do not use them, if at
| all possible. kitty contains features that do all of what tmux
| does, but better, with the exception of remote persistence.
|
| Bit funny, most of the time I'm running tmux in kitty (or ssh in
| kitty to a server with tmux).
|
| Remote persistence is a pretty massive deal, though.
|
| In general, I don't like getting attached to a terminal emulator,
| and mostly just try to avoid using any unique features they've
| got. If a terminal emulator and a command line program are
| competing for doing a task, the terminal emulator in some sense
| has an unfairly high hurdle to pass: if I become dependent on the
| terminal emulator to do it, then I can't replace the terminal
| emulator without also getting a new muscle memory for that task,
| if I ever want to switch terminal emulators.
|
| Which means it has to do that task so much better than the
| command line program that the delta is worth more than any
| possible improvements from switching terminal emulators. Kitty is
| a great terminal emulator but this is an absurd and basically
| unfair bar that it could never pass.
|
| In this case, though, it is actually worse than tmux because it
| can't offer the best thing terminal multiplexers do: remote
| persistence, which is _the_ killer feature.
| omoikane wrote:
| kitty seems to be a relatively more opinionated terminal
| compared to other terminals. The first time I heard about kitty
| was via a comment about not implementing Sixel support:
|
| https://github.com/kovidgoyal/kitty/issues/2511#issuecomment...
|
| "Terminal multiplexers are a bad idea" sounds just like Sixel
| being "an inferior graphics protocol", and Sixel is probably
| another example of "worse is better".
| bee_rider wrote:
| I have trouble laying that at the feet of Goyal, who was not
| really interested in the feature, but who was willing to
| provide feedback and appeared willing to accept a patch.
|
| The person working on the patch decided that they didn't
| think the sixel library (which they were the maintainer of,
| so they presumably had a well informed opinion) was up to the
| task.
|
| The description of sixels as inferior also came from the
| person working on the patch.
| godelski wrote:
| People have submitted patches and "hacks" and he shoots
| them down calling them too hacky but not saying how.
| fl0ki wrote:
| It's not like Goyal doesn't accept any patches [1].
|
| I don't use kitty myself, but many people who do seem to
| love it. I've come around to feel that this is truly a
| maintainer's judgment call. After all, they are almost
| always stuck maintaining the code no matter who wrote it
| initially, and they know better than anyone else what
| code they're personally comfortable maintaining.
|
| More generally, if you like a piece of software enough,
| you're implicitly trusting the maintainers' judgment.
| You're certainly not reviewing every single line of code
| they write to see if you agree with it. If they betray
| your trust enough then you move on, but if you keep using
| the program then the maintainers' judgment was right
| enough.
|
| The miserable survival rate of hostile forks also
| demonstrates that even if people care enough to fork over
| one issue, they rarely care enough to maintain the
| overall project long-term, despite implicitly asking the
| original maintainers to do the exact same thing.
|
| [1]
| https://github.com/kovidgoyal/kitty/graphs/contributors
| godelski wrote:
| No, but it does seem Goyal really dislikes tmux and is
| making the common misunderstanding that people use tmux
| for persistence more than formatting.
| fl0ki wrote:
| They did take over maintenance but abandoned it shortly
| after: https://github.com/libsixel/libsixel/
|
| You can add this to the enormous pile of open source forks
| that didn't survive long enough to have any real value to
| the industry.
|
| I respect that Goyal has been bitten by this dynamic before
| and said this back in April 2020:
|
| > That said, I wont refuse a patch to implement it on top
| of the existing graphics support, provided I was reasonabl
| confident the person implementing it would stick around to
| maintain it as well.
| sweeter wrote:
| to be fair, sixel is definitely worse than Kitty Graphics
| Protocol by literally every metric and sixel has 1/10th of
| the capability (like z-index, gif/video support,
| transparency, speed, color depth, X-Y placement, etc...)
| omoikane wrote:
| Sixel might be worse in every metric except availability,
| and availability matters quite a bit to user adoption:
|
| https://www.arewesixelyet.com/
| lofenfew wrote:
| I wouldn't say sixel is worse is better, since that would
| imply it had general success. Drawing with block
| characters/braille characters is worse is better.
| rmdes wrote:
| I'm into byobu because it allows me to choose tmux or screen and
| I've gotten used to how it handles new "windows" in my terminal,
| I mostly use it server side, so I can have persistence and have
| each tab window in the remote terminal running exactly what I
| want, combined with fish shell it's just a pleasure to work
| INTPenis wrote:
| Kovid may be right, but from a usability standpoint they're dead
| wrong.
|
| Users will gravitate towards what makes their life simpler, once
| it was screen and now it's tmux. Regardless of the technicality
| behind it.
|
| I actually gave zellij a try recently but went right back to
| tmux. Zellij seems like a very promising software but tmux still
| has a lower threshold of entry.
| sgt wrote:
| What's wrong with screen? I tried tmux about 15 years ago but
| didn't really see the major benefit. Has it changed much?
| gitaarik wrote:
| Yes, it has a bigger more active community with more features
| and plugins. I used to use screen all the time but then
| converted to tmux because of modern features that screen
| didn't support, at that time at least, like displaying
| certain Unicode characters and a way to restore a previous
| session. It was a bit of a hassle to make tmux work similar
| to screen and some things you have to really do in a
| different way, but overall I'm happy with the switch.
| INTPenis wrote:
| I can only speak from personal experience but I never got
| deeper into screen than running basic commands in a detached
| screen and re-attaching it.
|
| But with tmux the docs and ui were just so intuitive that I
| was a power user within weeks.
| swapsCAPS wrote:
| heh I notice I really don't care what any of the terminal
| emulators provide in terms (get it) of functionality. iTerm2 now
| has "AI". What? As long as I have my good ol trusty tmux setup
| I'm good. Since the multiplexer _is_ the middleman it has become
| the perfect place to implement functionality which would
| otherwise be emulator specific.
| leblancfg wrote:
| For me kitty's main upside is its configuration dotfile that
| can be version controlled. I used iTerm2 for years, but moving
| around multiple computers makes it harder.
| nephanth wrote:
| Imo, the killer feature of tmux is that not only does it persist
| your shell, it persists your workspace. If I ssh into my server,
| i'm going to find my whole session as i left it, with the same
| tabbing / panes.
|
| This is a need kitty+screen doesn't answer. If I close kitty &
| reopen it, i'll have to re-split every individual pane, and
| reconnect each of them and reattach them to the right persistent
| screen pts...
|
| Infact if there was a way to handle that "workspace-persistence"
| with terminal emulator-based workspaces, I'd ditch tmux in a
| minute
|
| EDIT: now that i think about it, this could maybe be achieved by
| keeping the terminal multiplexer's "server", but having the
| terminal emulator act as a client to it
| Ringz wrote:
| Running Kitty and having stable connections to all my servers
| means I never needed tmux. That's the point for me. If you have a
| stable connection, let it run in a separate tab, window, split--
| whatever--until it's finished. Digital life is complex and
| fragmented enough, so I avoid having to deal with another layer
| like tmux and call it a day. Keep it simple.
| kibwen wrote:
| But if I hibernate my computer twice a day, once to take it to
| work and once to bring it home, then twice a day my SSH
| connection will be killed due to hibernation (or even if I
| didn't hibernate it, it would be killed during network
| disconnection), meaning this setup is only good if everything I
| do fits into a single eight-hour workday, or if I work
| exclusively over a cellular connection with transparent network
| migration and never put my computer to sleep. Simpler to just
| have a program running on the server that I can attach to.
| dahart wrote:
| Knowing tmux means you can have persistent sessions between the
| console and the window manager, and means you can use your
| workflow on other people's machines, on machines without a
| stable connection, and on machines without Kitty or a GPU
| installed. I don't know about Kitty, and there doesn't seem to
| be universal love for it or it's author, but I can mention that
| tmux is scriptable which makes certain multi-shell workflows
| amazingly fast and useful. One web company I worked for built
| the dev environment around launching tmux and starting
| different servers in each tab automatically. This is really
| useful and elegant for debugging without having to sift through
| the combined output of these servers, made it easy to stop and
| restart individual servers, avoided the need to juggle files,
| etc. etc.. Hard to see these advantages if you haven't
| experienced it, but this setup is something I've adopted and
| carried forward to other companies because it's so nice.
| fb03 wrote:
| What if you are running a long running and important process
| and your personal internet connection drops, killing your
| process? That's why I am fond of screen and tmux
| hiAndrewQuinn wrote:
| OP here: I'm realizing tmux's/screen's remote persistence is a
| bigger deal for a lot of commenting folks than my dinky little
| "how do I put my logs on the right and my vim on the left" use
| case. Color me mildly surprised, I always thought screen
| splitting / multiple shells in tabs was the reason we were all
| using these.
|
| To be unambiguous, that's not the "worse is better" I'm talking
| about. That's straightforwardly better is better.
| kzrdude wrote:
| If I use a terminal with mosh with tmux with neovim with :term
| how many parses is that? At least 4 or 5. It works!
| syslog wrote:
| ,,If you want to walk the path of true digital minimalism,
| vanilla Vim and tmux or its spiritual grandfather screen are all
| you need."
|
| I think I've been walking this path for twenty years now.
| lisper wrote:
| > tmux (short for "terminal mux" (short for "multiplexer")) is i3
| for your terminal.
|
| What a weird way to describe it. It sounds more like an
| alternative to gnu screen [1] to me. Comparing either of those to
| i3 seems like a category error to me.
|
| ---
|
| [1] https://www.gnu.org/software/screen/
| granra wrote:
| Funnily enough I used to use i3 and later sway until I realized
| I just full screened everything (on different workspaces)
| except terminals. Now I just use gnome and attach to a long
| running tmux session where I split panes to replicate my old
| tiling workflow.
| tambourine_man wrote:
| I like tmux and have an extensive tmux.conf that I spend many
| hours fiddling with.
|
| But I end up using the native terminal a lot more. I love smooth
| scrolling, command key shortcuts and, for whatever reason, colors
| are a bit off when I log into Debian. These tiny details add up.
|
| Vim even has a built in terminal these days, so it's one less
| reason.
|
| But it's a nice utility to have in your belt for sure.
| thih9 wrote:
| What I like about tmux is that it in itself runs in a terminal.
|
| Its UX - like scrolling, copy pasting, pane management, etc -
| complements other terminal apps, resulting in a workflow that I
| find consistent and unobtrusive.
| sumosudo wrote:
| Ha. I've got two production sites running in tmux.
|
| Yeah I know. Crazy. Mad. Foolish. but its worked for years. Of
| course only two sites though, I swear.
| thayne wrote:
| Even if you ignore persistent sessions, there are some
| limitations with kitty's remote multiplexing functionality. For
| example some functionality relies on copying files, including
| executables, to the remote box, which may not be desirable or
| even possible. It also uses the ConrolMaster feature of ssh,
| which has some downsides, such as not being able to add
| additional port forwarding after the master session is created
| (at least on older versions of ssh, maybe that is fixed in a more
| recent version than what I use at work?).
| koinedad wrote:
| I'm not tmux master but I love using it to help organize
| different repos/projects I'm working on and especially when I
| need to run a long running query on a remote server it's a
| lifesaver. I made an intro video for my setup here if anyone is
| interested: My Simple Tmux Workflow https://youtu.be/hC5-j30olKc
| anthk wrote:
| tmux attach >>>> kitty
|
| That's it. Even with mosh it's useful. On latency witth escape
| codes and issues with vim/vis, set this at ~/.tmux.conf:
| set -g escape-time 10
| vegabook wrote:
| This geez wants to lock us into Kitty vs cross-terminal TMUX? ...
| and withouth attach/detach??
|
| Even a 386 running at 20 Mhz can trivially handle Tmux what's
| this whole "oh it has to parse keystrokes twice" malarkey?
| gavinhoward wrote:
| My perspective: https://gavinhoward.com/2022/02/goodbye-kitty/ .
|
| tl;dr: tmux has saved my work many times, and Kitty affordances
| do not make up for that. And it's an integral part of my dev
| environment: https://gavinhoward.com/2020/12/my-development-
| environment-a... .
|
| As an update, I'm on Alacritty.
| wazoox wrote:
| I go even farther: I often use tmux in screen or the reverse. For
| instance I'll open a terminal (generally rxvt), then run screen
| locally, and from within screen connect to various machines on
| which I'll run tmux (because I almost always want to run long
| running programs remotely, even if only 'apt upgrade ').
|
| And I'm not even ashamed
| quocanh wrote:
| An alternative: `zellij` is better is better. With `tmux` I never
| get the sense that I have "mastered" it. I simply don't know all
| the controls - I only have a few of my most commonly used ones.
| Stepping into `zellij`, I feel like I've mastered it within a few
| hours of using it.
| aerzen wrote:
| I've been using tmux for some time now and have gotten pretty
| good with it, but the other day I got fed up with small
| problems of copy mode and how it displays tabs, so i tried
| zellij.
|
| First impression: way too much visual clutter. Second, way too
| many key bindings I don't need. And one configuration file
| later: a perfect replacement for tmux, with just the right
| amount of features for me.
| zokier wrote:
| Huge swathes of terminal ecosystem falls into worse is better.
| Implementing terminal emulator in terminal is just on-par here.
| You can make all sorts of interesting arguments between the
| options, but ultimately there are no "good" choices here, its all
| more or less worse.
| kanodiaashu wrote:
| I ssh from a mac into linux servers for my everyday work.
|
| I went from tmux + vim TO (doom) emacs + tramp + projectile. I
| think I outgrew vim, and emacs EVIL gave me VIM but also magit
| and org and projectile. I tried to work in the emacs shell for a
| while. I realised I need tmux persistence still. Emacs shell also
| just doesn't do well with EVIL mode. So now I just do all
| development on emacs and manage runs etc through my tmux,
| occasionally still using vim on the tmux to manage config files
| when I don't want to load them into emacs because its a one off.
|
| I dk about kitty, but I'm a fan of Kovid Goyal's calibre. I can't
| imagine how I would live without a. multiplexing b.persistence
| c.returning me to my context. And I never have had any tmux
| problems.
| coxley wrote:
| Like some others in the thread, I started using Zellij last year
| and boy is it nice.
| KennyBlanken wrote:
| > Energy/performance wise they are poison, every byte has to be
| parsed twice, once by the middleman and once by the terminal
|
| I get that software bloat is a problem, but it's a little strange
| to hear a man whine about the overhead of a byte getting parsed
| twice as part of a terminal session when _ten years ago_ desktop
| computers had around 8-9GB /sec memory bandwidth and single-
| thread performance measured in multiple billions of operations
| per second...
|
| ...when he refuses to split out highly dynamic functions (the
| news parsers) of Calibre into a plugin so that he doesn't have to
| version-bump Calibre every time a newspaper slightly changes
| their website and breaks the parser, forcing tens of thousands of
| users to update the entire package (and he doesn't implement a
| self-updater, much less one with binary diff capability.)
| kashyapc wrote:
| The linked FAQ in the article says: "terminal multiplexers are a
| bad idea, do not use them, if at all possible".
|
| This sounds like the author seems to ignore the ground reality.
| For the vast majority of users, _tmux_ simply does its job and
| gets out of the way. They (we) don 't even notice these subtle
| issues. It's simply a non-issue.
|
| Stuffing the entire multiplexer into a new terminal emulator
| sounds like a solution in search of a (specialized) problem. Not
| just that, you now have two problems: first, you have to learn
| the new terminal emulator; then, get to the built-in multiplexer
| with its own quirks.
|
| The classic cliche of "do one thing and do it well" applies here.
| EasyMark wrote:
| tmux works well and I can prettify it. I don't care if it's the
| most pure or performant. It's plenty fast enough for me and I
| don't ever recall it crashing. I think what matters is results. I
| love the way it separates terminal functionality and sessions
| away from gui terminals. if my connection blips it's easy enough
| to log back in and resume my ssh connection. Functionality is
| king.
| LAC-Tech wrote:
| Kitty was the slowest starting terminal I'd ever tried.
| Noticeable delay when you spawned a new one.
| deanresin wrote:
| > Because it's always going to be there, and it does the one
| thing I actually need it to no matter what: Let me run multiple
| shells at once, without SSHing in multiple times, regardless of
| whatever funky terminal emulator I'm actually using to get the
| job done.
|
| I'm confused. Couldn't you just open a new tab to do this? Or
| just alias your shhing to a 4 stroke alias like "sshg"?
| camgunz wrote:
| I (of course) wanna plug Vim again here. Vim comes with a great
| terminal, you can arrange the windows however you want, you can
| save the layouts in your sessions, and the keybindings for doing
| all of it are real straightforward. I used to use some kind of
| terminal, some kind of multiplexer, and Vim, but now I just use
| (Mac)Vim.
| complex_pi wrote:
| As tmux is discussed: my setup is xterm + tmux with 'C-o' as the
| key binding. Conflicts with nothing I use and allows me to start
| screen while in tmux (don't ask :-O but sometimes tmux is local
| and I want a remote screen). The binding is also ok whether you
| use vi or emacs. What else could you want?
| znpy wrote:
| > [T]erminal multiplexers are a bad idea, do not use them, if at
| all possible. kitty contains features that do all of what tmux
| does, but better, with the exception of remote persistence.
|
| Kitty developer should really ponder on why people use terminal
| multiplexers in the first place.
|
| I do and here is the thing: i can live happily without kitty, but
| i can't live without screen (or tmux).
|
| Quite frankly i do use mac os built in terminal and it's fine? I
| do everything in a screen session anyway.
|
| If i want a better terminal emulator i have SecureCRT.
| andrewaylett wrote:
| In your `~/.ssh/config`, make sure you have:
| Host * ControlMaster auto ControlPath
| ~/.ssh/control/%C.sock ControlPersist 300s
|
| And SSH will multiplex as many sessions as you want into a single
| connection. If you're not using tmux to allow you to resume
| detached session, this works really nicely. I have fingerprint
| auth for the first session, to establish the connection, then I
| can connect and disconnect to my heart's content without
| authenticating again unless I have no connections open for 300s.
|
| I typically use plain SSH with persistent sessions, and connect
| over Tailscale so even if I go offline and reappear on a
| different IP address my session will probably survive. If my
| session doesn't survive, it's easy enough to start a new one :).
|
| The missing piece, from what others have commented about, is
| long-running commands. If I'm upgrading Debian over SSH then I
| _will_ do that in `screen`, but for pretty much anything else I
| 'd prefer to launch it as a (possibly ad-hoc) service and let my
| service manager look after it.
| erik_seaberg wrote:
| I nohup anything slow that isn't interactive, it's POSIX and
| the logged output might be useful if it dies halfway.
| idatum wrote:
| For remote SSH, I like to use an .ssh/config setting for the
| remote host and automatically start a remote tmux. Saved my work
| a few times from spotty connections from my laptop tethered to my
| phone. Something like this: Host t-sdf
| HostName sdf.org User idatum
| RemoteCommand tmux new -A -s mylaptop RequestTTY yes
|
| Then log in with ssh t-sdf
|
| and tmux is happily running a session named "mylaptop".
| Connecting again gets you back to the same tmux session.
|
| I use tmux daily and I haven't found a reason to switch.
___________________________________________________________________
(page generated 2024-05-25 23:01 UTC)