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