Tmux is worse-is-better | Hacker News Reader

Tmux is worse-is-better

hiandrewquinn.github.io

225 pointshiAndrewQuinn271 comments

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.

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.

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.

> 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.

> 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.

> It’s the arcane shortcuts

All of which can be configured.

> 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.

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.

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.

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.

Look into zellij

Have you tried `tmux-tilish` [1]?

It’s a tmux plugin that replaces the default Ctrl-b keybindings with the same keybindings used in i3wm (including turning on automatic tiling instead of manual splitting). Given that you use i3wm on your desktop, you might like it :)

[1]: https://github.com/jabirali/tmux-tilish

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)

you might want to give Zellij a try. (https://zellij.dev/) Works like tmux but with the UI friendliness of more modern apps.

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

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.

TurboVision from the 1980s or 1990s has draggable and overlappable windows inside a single shell/DOS screen.

https://tvision.sourceforge.net/tvQNX-pterm-photon.jpg

Yes but that's just writing to the vram directly, just as keyboard and mouse are read directly. Not the madness of going through heaps and loads of batshit crazy terminal extensions, escape codes and decades of cruft and hacks piled upon the tty.

That's not correct. Tvision has worked in terminals for almost as long as terminals have existed.

https://github.com/magiblot/tvision

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.termina...

Unfortunately zellij doesn't implement job control properly, so running certain daemons or other things that use process groups are very broken.

Try Byobu with mouse-mode on. It uses a tmux as a backend and provides complete control with a mouse, including context menus that allow you do all of the things you listed without obscure keyboard shortcuts.

    set-option -g mouse on

Drop that in your ~/.tmux.conf file.

Then you can create new windows or panes by right-clicking (and clicking on the drop down), click on a pane to focus it, click on a window name to focus it, right-click to rename it, drag to highlight text or to adjust the width of a pane, etc, etc.

> 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.

The cynical view is that non-standard features make your product sticky

So EEE is preferred now?

1) There are no standards 2) The problem happens when someone wants to add something new to the terminal ecosystem. 2a) Designing something becomes harder because it has to be designed to work with the horrible hack that is terminal multiplxer. The tty model is dead simple, one tty per child process. When you add a terminal multiplxer it completely confuses this simplicity, making it instead multiple processes per tty and does it in a way that is opaque to both the processes and the host terminal, leading to endless bug and incompatibilities. 2b) Any new feature is now gatekept by the individuals in charge of the multiplexer projects.

> There are no standards.

I don't agree with this. There are tons of standards (even if it's de-facto) from VTxxx to XTerm's emulation standards. If there were no standards, it wouldn't be possible to talk with a modern system using a real VT320 (Yes, we have these), or with a vintage system with a modern terminal over a TTYUSB device.

> The problem happens when someone wants to add something new to the terminal ecosystem.

I understand, but every decent standard should take what's done before them and be prepared to face with it. Let it be Ethernet, TTY, even something modern like DisplayPort. When people doesn't do their due diligence and spend the time required to handle edge cases, things are bound to break (e.g. Cheap monitors' firmware contains identical serial numbers, causing all types of shenanigans in multi-monitor setups).

> 2a) Designing something becomes harder because it has to be designed to work with the horrible hack that is terminal multiplxer.

For harder part, see the previous paragraph. i.e.: One should do their homework to work with other systems. On the oh gawd horrible hack! part, That "horrible hack" is saving hours of work per month per person who work with remote servers for ~30 years now, and nobody is planning to give them up AFAICS.

> The tty model is dead simple, one tty per child process. When you add a terminal multiplxer it completely confuses this simplicity, making it instead multiple processes per tty and does it in a way that is opaque to both the processes and the host terminal, leading to endless bug and incompatibilities.

Maybe one should draft a new standard about multiplexing terminals persistently without it being a hack? There's a big gap there, as you point out.

> 2b) Any new feature is now gatekept by the individuals in charge of the multiplexer projects.

Both screen and tmux are maintained properly, and they fix the bugs they cause actively. For example, screen was causing a problem in SGR mode, and they fixed it 2 months ago [0].

Oh, on SGR; it's an ECMA Standard. Standard-48 to be more precise [1]. So, again, there are standards, and you can build new ones, and I bet, terminal multiplexers will play along if you don't throw eggs at them.

[0]: https://git.savannah.gnu.org/cgit/screen.git/commit/?id=c184...

[1]: https://www.ecma-international.org/wp-content/uploads/ECMA-4...

A de-facto standard is not a standard. It's an opinion.

I suggest you go plug a VGA cable into a DisplayPort and see what happens.

The horrible hack is saving you and the few other very loud people that use it hours of work. I for instance have been using remote servers for 40 years without ever needing a multiplexer. They have always been, and remain, horrible hacks that I rejected when I first came across them and that have been a drag on the entire terminal ecosystem for 30 years. Thankfully they are finally on their way out, thanks to a new generation of terminal emulators and are using the tty the way it was designed to be used.

The new standard is the old one. Use the tty as it was intended and designed without a horrible hack in the middle. And if you really need remote persistence via a multiplexer of all things, then use one provided by the terminal emulator you use so that it integrates natively, seamlessly and correctly with the terminal emulator. Granted currently only WezTerm provides such a multiplexer, kitty for instance instead multiplexes SSH access via SSH control masters. But its developer has indicated he will someday write a tmux replacement that is kitty native.

Oh and on SGR it is an ECMA standard, only in the breach. For example, color support as it is actually used in terminals violates the so called specification.

As for multiplxers playing along, here you go: https://github.com/tmux/tmux/issues/1391

Complete and utter drag on the ecosystem.

> A de-facto standard is not a standard. It's an opinion.

OK. Let's look what happened some of these opinions.

    - PDF became two different ISO standards.
    - USB started as a de facto charging port, became de jure in EU.
    - DMX, MIDI, DE-9 RS232 connectors are all de-facto standards, but used as de-jure now.
    - Tons of file formats in scientific and engineering computing is in fact de-facto standards, yet they flourish.

So, it's meaningless whether a standard is de-facto or de-jure. If it looks/walks/sounds like a duck, it's a duck.

> I suggest you go plug a VGA cable into a DisplayPort and see what happens.

I use something similar to this [0]. It works.

> The horrible hack is saving you and the few other very loud people that use it hours of work.

I love how you liberally throw the h-word around. Because horrible hacks became conventions over history. Vi's latency hiding can be considered "a horrible hack", or "brilliant" depending on the perspective. Same can be said for HDMI for example. Piggybacking on DVI for video signalization, adding a couple of digital lanes for sound and Ethernet, it can be considered a horrible hack, yet it's a de-jure industry standard. IOW, someone's opinion, just in a written form with some stamps and a logo.

From my vantage point, people not using terminal multiplexers (tmux/screen) are a shrinking minority, yet from your perspective it's the opposite. Considering the oh gawd horrible terminal multiplexers are still maintained, and I still initiate people on screen or show them tmux as a screen alternative, I don't see they're going anywhere. Your perspective may differ. I'm mostly talking about younger generations, I may add.

> I for instance have been using remote servers for 40 years without ever needing a multiplexer.

I think you're lucky for not having to debug things on the go, for days, or managing servers on a responsive and stable network. I sometimes have no luxuries, so I have to use horrible, horrible hacks to get things done. It works brilliantly unfortunately. Shame on me.

> I rejected when I first came across them and that have been a drag on the entire terminal ecosystem for 30 years.

That's a long grudge to hold. I'm sure it's not the only one. Think about your health. No it's not meant to snark. I'm honest.

> Thankfully they are finally on their way out, thanks to a new generation of terminal emulators and are using the tty the way it was designed to be used.

I don't see it's happening, sorry. What I see is more hacks are piled upon hacks. Some might stick and become standards, some might die.

> Granted currently only WezTerm provides such a multiplexer...

Wezterm's multiplexer is a regular old multiplexer which connects to a remote wezterm instance. IOW, just a different transport which encapsulates a WezTerm instance. There's nothing magic here. It's moving the hack to another layer. Now there are two transports, and Wezterm's one is not interoperable with others. So it's a really horrible hack from my perspective. If something is not interoperable with other tools, then it's out for me. I can't be bothered to install Wezterm to all and every server I work with. Which is >1000.

Unfortunately, I have the luxury of choosing the terminal which I want to work with in any circumstance. As long as I can connect to my remote server, my persistent workspace is there. I don't need a local Wezterm to be able to work.

> ...without a horrible hack in the middle.

Wezterm puts the horrible hack on top. Like a cherry. Bright and eye-catching, in a bad way.

> As for multiplxers[sic] playing along, here you go: https://github.com/tmux/tmux/issues/1391

I read the bug report. I think the problem is the approach. If somebody is so adamant in a feature, and the maintainer doesn't want to add that feature, a) you can patch it yourself, b) you can fork and patch it yourself. It's free software. The tmux maintainers doesn't owe you anything. I bet, if you send in a nice patch, they won't ghost/reject you.

BTW, a mux is just another terminal emulator inside your terminal. It's not more of an hack compared to an ncurses window, or old graphic interfaces in UNIX systems.

> Oh and on SGR it is an ECMA standard, only in the breach.

Many standards are flexed. Many graphics cards do not fit inside the PCIe mechanical standard, for example, but they work.

> For example, color support as it is actually used in terminals violates the so called specification.

My terminal has fallbacks for a lot of modes. This is what backwards compatibility is for.

> Complete and utter drag on the ecosystem.

Sorry I don't see/feel it for the last 20 years.

So, in short, I agree to disagree, and genuinely wish more power to you in your endeavors. There are no hard feelings here, just tone-matching.

Hope to have a longer chat and have the opportunity to learn from each other.

Cheers!

[0]: https://media.startech.com/cms/products/gallery_large/dp2vga...

I'm going to ignore the personal attacks since you seem to want to genuinely learn something.

1) The difference between WezTerm's multiplexing and say tmux, is that wezterm's multiplexing supports all the same features/bugs/syntax and quirks as WezTerm itself. It does not have to translate between what it gets from an unrelated terminal implementation that it has only the most superficial information about to its own internal representation and back, which is what a multiplexer like tmux has to do. Tomorrow if Wez decides to add a new feature to WezTerm, he can add it to his multiplexer at the same time. Thus, the WezTerm multiplexer is a) much more robust than tmux b) not a drag on the entire ecosystem since nothing other than WezTerm itself depends on it implementing anything.

And therefore, unlike tmux, it is not a horrible hack.

To put it another way, tty's are sufficiently complex that multiplexing if needed at all, must be done by the terminal emulator, not an unrelated third party sitting in the middle. You say a multiplexer is another terminal inside the first, I say that is precisely the problem. It is an incompatible terminal emulator.

I wouldn’t call it “breaking standards” as much as “introducing new standards”.

The protocols introduced by Kitty, like the Kitty Graphics Protocol and Kitty Keyboard Protocol, were sufficiently well-documented that other modern terminals (e.g. WezTerm) have adopted them as well. Moreover, both protocols offer advantages cf. the modifyOtherKeys and Sixel standards used by e.g. xterm.

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.

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.

This is my favourite, I use it all the time. There's a couple bugs that show up but it's really good. Having real local tabs for a remote SSH is great.

Anyone know of a terminal for Linux with this feature?

I haven’t found a great Linux terminal: it’s one of the things that really makes it hard for me to use Linux

What? Xterm is amazing.

Parent means with those kind of features something like iTerm has

iTerm2 has a ton of quality of life features that no alternate terminal comes close to: automatically detecting tables in output and handling copy/paste correctly. Quick navigation between shell prompts, etc.

If emacs wasn’t really slow with long lines in buffers and high volume output, it could be better

The correct way to handle copy and paste in a terminal is to copy what is selected verbatim and to paste whatever is in the clipboard verbatim.

Interpretation of intent and “helping” the user are neither needed nor desired, and at best leave everything alone and at worst misinterpret and get in the way.

I have never copied anything out of a terminal and gotten anything other than what I copied when I pasted into sublime text, and I’ve never used iterm2.

Are you talking about copying from a terminal and pasting into OneNote or some other “more than plain text” application or something?

No, I’m talking about noticing that you have a tmux or vim split and restricting the selection to one side or another of the split so that you can select the actual text rather than some random nonsensical text.

This is the single feature I miss the most in any other terminal emulator.

Ah, ok. I don’t use tmux or any other multiplexer, I handle that problem differently.

I prefer manual control. Simply holding down Ctrl while selecting creates a rectangular selection in pretty much every terminal, which works in all those cases.

People tend to get attached to certain methods/ways and then defend that no matter what.

At least in the terminals I’ve used so far, holding down Ctrl causes you select the displayed form, not the verbatim form of what you’re highlighting. That is, if you’re in vim looking at a file with 10 long lines, selecting them this way will only select the portion that fits onto your screen, not the entire lines. And if your editor visually wraps them so they do fit on the screen, selecting this way will introduce unwanted line breaks, such that copying 10 lines and pasting can create 23 lines.

The iTerm2 feature being discussed means that selecting works the same way it does for graphical programs like Gedit or Pycharm or Word — if you select 10 lines you select 10 lines and your window size, font size and visual wrap setting don’t factor into it, and when you paste, you paste what you copied as it was. I would say this is the intuitive and reasonable behavior, but it’s one that is not simple to implement. A visual word wrap should be a purely visual thing and s back to back Cut and Paste should result in nothing changing.

Good point, didn't think of that, probably not encountering that case often enough in my workflow.

copy what is selected verbatim

Does that include all trailing whitespace in the rectangle you selected? Should your selection automatically minimize to unselect said trailing whitespace (even before copying, I mean)? Should a selection preserve tab characters or replace them with spaces? What if the selection does not start at a tab boundary, should it ignore or include the half-selected tab instance?

I don't think there is a singular answer to what "copy selection verbatim" means.

> automatically detecting tables in output

What is this? I've been using iterm2 for years and don't know about this (and can't seem to find anything mentioning it).

https://apple.stackexchange.com/questions/364888/how-can-i-l...

“Tables” is imprecise, but is one use-case: it’s more about identifying soft boundaries like the lines between tmux or vim splits and limiting the selection to one side of the split. If you have pipe-delimited tables, it lets you select a single column of values.

!!! THANK YOU !!! (and George Nachman) I had no idea this existed and this is a dozens-of-times-daily pain point for me.

I just tried with kitty, and konsole, on linux and selecting text within a tmux split works perfectly. So does copy-paste (use Ctrl-Shift-C instead of Ctrl-C).

Is this through tmux’s mouse mode? Can you select three lines of only the left side of the session? Does this also work in vim and other places that draw soft boundaries on the screen?

I just tried this in kitty and it didn’t work

Yes I see what you mean. I have tmux mouse mode enabled which makes this possible. This works in nvim as well because it also has mouse support. Presumably iTerm supports selecting text in a single pane even when you have mouse mode turned off.

IMO this setting belongs with the application, and especially with tmux and nvim supporting this natively, you don't really need the terminal itself to implement some potentially fallible heuristic. For example with iTerm if you accidentally drag outside the pane boundary, the selection immediately expands to include both the panes, which is not ideal.

I like it because I can design programs to output pipe-delimited tables and selection works correctly (I also hate terminal apps that use the mouse and disable mouse mode everywhere so that mouse selection in the terminal works predictably)

"handling copy/paste correctly."

Sometime in the last year, iterm2 started adding ~00~ crap around stuff I paste. then some yellow 'alert' box at the top indicating I'm doing something wrong and do I want to keep doing it. makes 0 sense to me, and... annoying because it didn't do it for the first... 6-7+ years I used it. My behaviour didn't change, but iterm2 starts breaking.

No doubt there's some 100% logical explanation as to what changed such that my standard copy/paste is 'wrong' now, but... would have preferred they'd have kept the original behaviour.

This is probably the bracketed paste feature: https://invisible-island.net/xterm/xterm-paste64.html

There’s a toggle in the terminal settings

Just wanted to note for everybody who really loves this feature. There is some options here though

Wezterm terminal supports multiplexing from the box: https://wezfurlong.org/wezterm/multiplexing.HTML

Also, there is Hyper terminal, and standalone protocol to implement multiplexing https://www.reddit.com/r/commandline/comments/q5mj11/htm_a_c...

If you know other options, please share.

I work in windows, but at home I use macos, so I stick to wezterm. I use it with single config for both platforms (config is written in Lua)

Wezterm does not have good enough multiplexing like tmux. such like you have not easy way to switch/create sessions.

>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.

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.

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.

As I said, on connections it's spawns a daemon on target machine that will do exactly that - keeping the State despite clients disconnection

oh, sorry. i didn't read your comment close enough. that actually sounds interesting. i'll have to take a look. although i prefer mosh over ssh because it is more reliable with the slow connection that i have. however if wezterm can reconnect like mosh that might work. thanks.

> 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.

Reminds me when he said he'd maintain the entire python 2 language instead of upgrading Calibre to use python 3

https://bugs.launchpad.net/calibre/+bug/1714107

There are a lot of other gems too if you look through Calibre's bug tracker

https://bugs.launchpad.net/calibre/+bug/885027

https://bugs.launchpad.net/calibre/+bug/1894442

https://bugs.launchpad.net/calibre/+bug/853934

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.

it's a foss project: http://www.9bis.net/kitty/ https://github.com/cyd01/KiTTY

Not that KiTTY, this kitty: https://sw.kovidgoyal.net/kitty/

But it's also foss, so, you're still right.

> Offloads rendering to the GPU for lower system load

My God, what have we done

What's wrong with that? Computing history has a lot of machines with various co-processors which are used to offload various things from main CPU. Just as an example: Amiga and C64 had both co-processors for rendering text faster.

Keystrokes!! Way to come up with a strawman. Every byte that the program running inside tmux send to the terminal has to be parsed and re-interpreted by tmux first and then the actual terminal. Same for every byte that the terminal sends the program running inside it. These include every byte used to redraw the screen, which with modern full screen applications like editors can be several kilobytes per screen refresh. Keystrokes indeed. This reduces throughput by a factor for 2 at a minimum, reference: https://sw.kovidgoyal.net/kitty/performance/#throughput see the table entries for alacritty vs alacritty+tmux. And that is just throughput, tmux will affect latency as well, though I dont have a reference to measurements handy at the moment.

Just off the wall crazy shit dealing with absolutists like this.

Yes efficiency is good. But... Damnit man! The performance numbers shown for this low power processor are 43MB/s without tmux vs 30MB/s with tmux. It's likely going to take a lot of activity for that to aggregate into even a decent fraction of a ms of latency.

Beware extremists. Some people will never be pleased, will accept nothing. The only answer is to cut cut cut forever. There's a cult of people out there that idolize performance above any practical use like a god & will destroy & savage anything else. Deny this falsity. Respect performance, but also allow other factors to balance in.

(Side note: I'd love to know how dtach performs. It has the key advantage to me of tmux, which is detachability, but no virtualization. Great for running a vim session! And by design is a very pure simple pass through.)

First I dont know what table you are looking at, but its 54MB/s vs 24 MB/s on average across different data types. That's a factor of 2. Aka half the throughput. I dont know what kind of performance engineering you do, but a halving of throughput is a pretty serious performance regression where I come from.

Also, latency is not a direct function of throughput. The two are separate. In this case the latency will come because when you have tmux in the middle it means your command line program writes to a pipe, which is a buffer in the kernel. tmux then has to read from that pipe, then it has to process that byte updating its internal state, then it has to generate the output bytes based on the internal state, those output bytes are written to another pipe, and finally the terminal reads from that second pipe.

There is a whole extra pipe with associated context switches for every byte (or more accurately every packet since reads/writes on a pipe are buffered). This will add latency for example for every keystroke no matter what the throughput numbers are. A pipe operation requires a poll on the pipe fd which is a context switch. Apart from whatever internal processing tmux does, there are four extra context switches added for every keystroke + response.

The table you linked is chopped off on mobile. So you are looking at the last column and the person above is looking at the first column.

Also, why have you done an “alacritty” vs “alacritty+tmux” benchmark yet have not done a “kitty+tmux” benchmark on this same table? That’s a big omission. The entire conversation is about the effects of adding a multiplexer on top of a terminal.

I didnt do the table go ask the kitty developer why he did that. Or just read the notes under the table where he tells you why he included alacritty+tmux.

Yeah very weird article, having so many benchmarks but not testing the main thing they are griping against except in one case.

I chose the ASCII column because it's 99.999999% of what 99.9999% of developers see.

> parsing each keystroke twice

I think it's an unavoidable cost for any remote re-attachable system. No matter it's tmux/vnc/whatever remote protocol. But even in all these options. Tmux is still the lightest weight among them. Which can runs on a 500mb-memory vm totally fine. Spin up a actual desktop is way way more heavier than a terminal emulator like tmux. And allow you to split the terminal is just a free bonus tmux provided.

In an ideal world, connection can live forever, so re-attachable protocols like those are totally unnecessary. But in reality, the network sucks often.

> 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

tmux over mosh over wireguard is all you need

why the wireguard step?

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

... except for the UDP port where wireguard receives its pakets.

yes, but wireguard is undetectable because the server won't reply to packets that fail auth whereas sshd will respond (with a banner!) to anyone who comes knocking

stealth is basically impossible with TCP

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.

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.

Is there anything better than tmux for this purpose? I need persistence but hate the key bindings and general interface.

My use-cases are pretty basic, and my use isn't all that frequent, but I've been very happy with: https://zellij.dev/

There's still `screen` ? Also, I think tmux keys can be rebinded ?

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)

Byobu just works on top of either screen or tmux. By default it will try to use screen, but you can force it to use tmux with byobu-tmux.

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/

+1 for dtach. That plus mosh and emacs works extremely well with no fuss.

Depending on exactly what you mean by persistence, there's always mosh.

I just use emacs. When my terminal drops, I just `emacsclient -t` and I'm back to work.

Sounds like you might like Zellij: https://zellij.dev/

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?

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.

What about scriptability? Is Zellij as hackable as Tmux to create different plugins?

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.

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?

yes, it does.

I love tmux and hate the default hotkey

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.

You can even use a sequence to activate it -- my prefix is "typing ` twice within x ms" and it avoids conflict.

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).

> 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.

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.)

You’re right! Thanks, yeah I can’t live without ctrl-a either, I use that all the time.

Yeah. Also happens to clash with my preferred window manager's prefix key (ratpoison).

Yes, I use C-z instead of C-b

Yes, I like to use a backtick (`). Pretty nice except when typing in markdown, where I need to type a double backtick for each backtick.

I use abduco for persistence - a very, very simple piece of code that -only- provides a persistent session, with one (configurable) keybinding to detach.

If you also want multiple terminals and screen splits and etc. it's designed to work with dvtm (by the same author) which provides that side of things.

Personally I tend to have a 2x2 grid of xterms on my local machine and four ssh connections to matching dtach sessions named project-{tl,tr,bl,br} but I suspect most people who aren't me would be happier with dvtm.

Mosh is great if you have spotty, high latency connection with a lot of packet loss.

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.

Nowadays everybody is in a GUI terminal emulation anyway. Multiplexing is completely redundant.

I imagine everybody uses screen and tmux mainly for remote persistence.

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

> 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

This is exactly what iTerm2 tmux integration does. Tmux exposes a "raw" control mode by starting it with the -C flag. iTerm2 uses this to convert tmux windows into native tabs/windows, complete with workspace persistence.

AFAIK, iTerm2 is the only terminal emulator to integrate with -C controle mode, which is probably the main thing that keeps me on macOS over Linux.

iterm2 tmux integration is the bees knees - I didn't find anything like it elsewhere.

> 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.

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".

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.

People have submitted patches and "hacks" and he shoots them down calling them too hacky but not saying how.

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

No, but it does seem Goyal really dislikes tmux and is making the common misunderstanding that people use tmux for persistence more than formatting.

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.

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...)

Sixel might be worse in every metric except availability, and availability matters quite a bit to user adoption:

https://www.arewesixelyet.com/

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.

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.

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?

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).

Tmux lets you make a pane toggle full screen. That’s reason enough for me.

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

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.

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.

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.

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?

Hyperlinks refers to "OSC 8" which is an escape code for making clickable links. for GNU Screen (released versions in my distro) this is an unknown escape and is stripped, tmux "passes it on" to the surrounding terminal and it is then usable.

Programs such as GNU coreutils ls (ls --hyperlink=always) can use hyperlink escapes in the outputs to make every file name it lists clickable, for example.

Of course there are ways to escape these escapes and get them to pass through screen - I wrote an escape code script myself to do it - but that experience is still inferior to native support, which tmux has nowadays.

Well I used GNU screen for a long time but it finally broke through now due to truecolor, and I managed to switch :)

I tested both zellij and tmux before switching, I was considering zellij as the first alternative. But zellij had some noticeable performance problems compared to tmux when it comes to throughput of terminal output, so I picked tmux.

See Neovim v0.10 changelog for how they use hyperlinks/OSC 8: https://gpanders.com/blog/whats-new-in-neovim-0.10/#hyperlin...

Can you post your tmux config that mocks GNU Screen?

Here is mine : https://pastebin.com/ZVWYcpyU , but a lot of GNU Screen muscle memory fails for various reasons.

The main reasons I'm trying to switch are: better scrollback support, and better mouse support (both for tmux itself and for pass-through to terminal applications). Having used GNU Screen for 32 years, it's difficult for me to even think about what keys I'm hitting, it's below the level of conscious recognition at this point.

Here is mine - it's pretty short. I think it reflects what I use and don't use, so I'm not sure it's useful to you!

    # remap prefix from 'C-b' to 'C-a'
    unbind C-b
    set-option -g prefix C-a
    bind-key a send-prefix
    bind-key C-n next-window
    bind-key C-p previous-window
    
    unbind C-a
    bind C-a last-window
    
    unbind A
    # Default C-a ,
    bind A command-prompt -I "#W" "rename-window '%%'"
    unbind k
    bind k confirm-before "kill-window"
    
    bind Escape copy-mode
    
    # start counting from 1
    set -g base-index 1
    setw -g pane-base-index 1
    
    # vi keys scrollback
    setw -g mode-keys vi
    
    # Style
    set -g status-bg black
    set -g status-fg white
    
    # Make current tab visible
    setw -g window-status-current-format "#[reverse]*#I:#W*"

IIRC, iTerm2 has special support for tmux. E.g., tmux panes get corresponding iTerm2 panes?

> 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).

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.

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.

> vim usually only one file at a time,

The big advantage of using a single Vim instance for everything is having all my registers shared.

I can copy something into register 'a' from file One.txt, and then paste 'a' into file Twenty.txt. Same with recording macros, command history, etc.

If any of those buffers are terminals, then I can use them just like a read-only file: copy from them into registers, run macros within them, etc.

The advantage, to me, of using Vim over Tmux, is that that I don't need to remember an additional set of key chords for moving between splits and tabs, and for resizing splits, etc. Using tmux requires additional commands and key chords to memorise.

I used to love tmux before vim had `:terminal`, but since Vim got `:terminal` there's nothing I get from tmux that I don't get in a simpler and easier way from Vim.

If I ever need to copy between instances, I use the + register for the system clipboard. There is only one but generally it's good enough for me.

If I'm expecting a lot of copying between files, that's when I will break my own rule and temporarily use a split window inside vim.

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.

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.

I nohup anything slow that isn't interactive, it's POSIX and the logged output might be useful if it dies halfway.

> 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.

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.

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

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).

Doesn’t ^z and bg solve this?

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”.

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.

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.

SIGHUP

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

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/

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.

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.

What is the advantage/use of Windows compared to some Linux desktop in your setup?

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.

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!)

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.

Possibly tmux buffering output. Control C kills the process immediately, but there's still 15 seconds of output in the pipe.

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.)

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.

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.

>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.

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.

What's wrong with screen? I tried tmux about 15 years ago but didn't really see the major benefit. Has it changed much?

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.

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.

Only problem ever was the metacharacter Control-A. We didnt like it, because it messed the workflow in Emacs and Bash.

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.

To me, the only annoying thing with tmux is copy/pasting across different setups and how inconsistent / flaky / tricky it is to get working.

I use different escape keys for my local and remote sessions and after many years I don't get confused anymore.

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.

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.

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.

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.

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.)

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.

For this reason I usually run screen locally and tmux remotely, that's good enough IMO.

Yeah that's why I use Kitty tabs for every single tmux session I run :)

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.

Thanks!

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.

I would be lost without tmux, if you have a regular ssh date with some machine it’s a life saver.

bad for energy? sir i code typescript in tmux

You’ll need gpu acceleration

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.

Like `tmux -CC` and iTerm2?

https://iterm2.com/documentation-tmux-integration.html

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.

> > [Terminal m]ultiplexers add unnecessary overhead, suffer from a complexity cascade, because they actually have to translate escape codes, modifying them in hackish ways to get them to work with their concepts of windows/sessions. […]

So... like how a terminal emulator translates escape codes, modifying them in hackish ways to get them to work with X's/Wayland's/users' concepts of windows/sessions? :)

Obviously that's not an apples to apples comparison but really, while that may make it more complex and slightly buggier I don't see how that makes it bad.

> I find myself typing out “tmux” as the first command I run. 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

I don't understand why people hate opening up another SSH session. If you're really worried about the 10 seconds it might take, you can easily configure it to take more like 1:

       -M      Places  the  ssh client into “master” mode for connection shar‐
               ing.  Multiple -M options places ssh  into  “master”  mode  but
               with confirmation required using ssh-askpass(1) before each op‐
               eration that changes the multiplexing state (e.g. opening a new
               session).    Refer  to  the  description  of  ControlMaster  in
               ssh_config(5) for details.

The only reason I ever use screen is for persistence, the multi-windows is just a secondary feature.

(Since when is tmux "always going to be there"?)

> I don't understand why people hate opening up another SSH session. If you're really worried about the 10 seconds it might take, you can easily configure it to take more like 1:

Well, for one example, when you have an SSH key with a passphrase, you need to enter the passphrase at the start of every new SSH connection. If you are working with multiple servers continuously and lose your SSH sessions when your PC goes to sleep, it's quite nice to have tmux.

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/

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.

how do you attach to a tmux session via ssh?

You SSH in and run `tmux attach`

ssh -t -A yourhost.com "tmux attach -d"

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

tmux a

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'

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

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?

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.

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.

I'm offput by the visual clutter myself. Please share the config to get over it.

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.

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 cliché of "do one thing and do it well" applies here.

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?).

One of the things I like most about tmux is the scrollback buffer, which you can scroll through and search and copy/paste any text in the shell output with vim-like keybindings (you have to configure it for vim-like keybindings, otherwise it's emacs style). It makes my workflow very efficient. I haven't found a terminal emulator with such convenient features and keybindings. And searching, copying and pasting are things that I do a lot in my terminal.

„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.

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.

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

> 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"?

> 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/

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.

Exactly, this comparison seems like an insult to tmux. I tried i3 because of all the hype (and lack of sensible arguments to use it), and in an hour realized that it forces me to manage things I did not need to even think about on a normal system. Also, it did not improve my productivity, it slowed me down trying to figure out how to manage my windows.

Tmux is great because its features work out of the box without a need to customize anything, this is a common trait of a useful and popular software (bash, ssh, coreutils, curl). i3 is not even close to this.

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.

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

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.

Like some others in the thread, I started using Zellij last year and boy is it nice.

         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

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.

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.

> [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.

Tmux got a new life, because you cannot have several terminal screens in Termux (of Android).

Screen was not good, because Control-A is important in both Emacs and Bash.

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.

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.

Some time ago I reported an energy wasting bug in tmux, and surprise twist, it was not the result of parsing every byte twice.

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!

Zellij is an order of magnitude better than tmux. Main issue with tmux was that it always messed up my TERM.

Kitty was the slowest starting terminal I'd ever tried. Noticeable delay when you spawned a new one.

> ctrl-b % ctrl-b "

I thought everyone mapped it to ctrl-a

Then I have mapped | and - to split screen horizontally and vertically

I try to remap my programs' keybindings as little as possible, as a general rule.

Sometimes if I see an advantage that's both big and obvious, I'll take the plunge and remap. Like as a teenager when I realized switching to Bumper Jumper in Halo 3 would make me much better with aerials, because I could turn and jump simultaneously. Otherwise the annoyance of having to relearn the command bindings any time I'm not at one of my preferred interfaces just doesn't feel worth it.

That being said, I did recently get one of those fancy split keyboards which lets you remap the keys. Ctrl is something I trigger with my thumb now, not pinky, and so C-b feels as natural as C-a would at a normal laptop keyboard.

ok that makes sense, I have caps-lock mapped to ctrl, so ctrl-a is the obvious mapping for me.

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.

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.

I know what you mean, but again, I never need that and the investment in tmux is to high for edge cases. Btw: Long running jobs are easy with a cron job:

echo "/path/to/long_process.sh" | at now + 1 minute

You never let your PC sleep when you're having lunch or something?

I do. No Problem closing the lid on my MacBook M1. I can open the lid and keep on working where I left.

I use kitty and the kitten ssh [1] to login easily to remote hosts, and automatically setup the environment.

I can use a simple bash like

  #!/bin/bash
  kitty @ launch --type=tab --title='Server 1' bash -c "command1; exec bash"
  kitty @ launch --type=tab --title='Server 2' bash -c "command2; exec bash"
  kitty @ launch --type=tab --title='Server 3' bash -c "command3; exec bash"

If I need several servers at once. Could be done with other shells too.

I can run loooong processes on the host with a simple bash script and the marvelous `àt` [2] command that nobody seems to know any more like:

  echo "/path/to/long_process.sh" | at now + 1 minute

And the team can reuse those simple bash scripts!

If `at` is not installed, and you need to run multiple looong tasks, try `nohup` [3]. Another lost command full of great functions like:

  nohup command1 &
  nohup command2 &
  nohup command3 &

If you and your team is happy with tmux, that's fine! But doing more or less the same things with easy linux commands is – in my opinion – the better way.

[1]: https://sw.kovidgoyal.net/kitty/kittens/ssh/

[2]: https://linuxhandbook.com/at-command/

[3]: https://www.howtogeek.com/804823/nohup-command-linux/ and https://stackoverflow.com/questions/5164985/how-can-i-use-no...

Edit: Formatting

OP here, today I learned about the `at` command. Thanks!

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.

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

That’s valid, but how often does it happen? It never happened to me. Long running jobs are easy with a cron job:

echo "/path/to/long_process.sh" | at now + 1 minute

And it adds the benefit to simply call that script again, if you need the same long process again.

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?

> 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.)

[flagged]

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.

i am usually to lazy to replace the default terminal. most of the time i did that i found some problem that gnome terminal didn't have. rarely i found features that i wanted in other terminals.

but occasionally i get curious, so lets try this:

1: ugh, the theme is dark. gnome-terminal also starts with a dark theme. i go into settings to change that. there doesn't seem to be a settings gui so let's look at the documentation. no mention of switching themes there. a search online reveals that i need to run "kitten themes". there are tons. the day theme looks good to start with.

2: font is to small. ctrl-shift-+ helps. i don't frequently open new terminals so this is good enough for now.

3: attach my already running tmux session. (sorry but i use tmux for the one thing that kitty doesn't support: persistence). works. no problem there.

4: next up: connect to a distrobox container where i do dev work. no support for xterm-kitty terminal type. reset $TERM to xterm-256color, phew. now it works.

5: open new tabs. manpage has a nice table of the necessary shortcuts. i like ctrl-tab because i can do it with one hand.

6: let's look at my email (sup-mua runs in a terminal). oh there is a problem with the colors. the status bar is hard to read. let's try another theme. adawaita shows the list white on white? huh? ok, CLRS seems reasonable. github theme looked better, but the fish terminal colors were to bright, especially the git commands. ironic.

7: faded tabs look ugly. tab_bar_style powerline looks better.

i think that's it for now. hopefully i don't have to spend more time with configuration. i am not really a fan of having to fiddle around to much to get things working.

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.

;)

This thread has given me some ideas to toy around with and maybe add to https://andrew-quinn.me/cli/ , let's say. That feels so wrong... but oh, so right. Who needs systemd when you've got a Pi and tmux?

why not just say "less is better?"

Because that's not the common, generally accepted term.

Because "Worse is Better" entered the lexicon circa 1991.

https://en.wikipedia.org/wiki/Worse_is_better

yes, why? seems like not that useful of a phrase if it needs an explanation with parenthesis in a wikipedia

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

Ah so it’s more “if it’s not broken enough, don’t fix it”

Read the essays, they're excellent.

> it is better to start with a minimal creation and grow it as needed

yes, this is a much better explanation than the wikipedia

Exactly. "Worse is better" makes zero sense.

It doesn't convey the same idea

What idea does "worse is better" convey to someone who hasn't heard of the phrase before?

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.

"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".)

"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.

Reply on news.ycombinator.com