What are you talking about, kernel panics are part of life with consumer hardware. They would happen even if it was windows?

You're right. I don't use SSH that often due to kubernetes, infact I only use ssh for connecting to my desktop to access my tmux sessions and it's great. I know where you're trying to go with this and it's simply not true.

Who said anything about tmux? We're talking about neovim which is extremely light weight and the LSP's don't sit around being active all the time. They have a set duration where they terminate when unused which is simply not possible in most IDE's (LSP based ones are OK, but have problems reconnecting).

you mentioned tmux. are you gaslighting me? lmao.

and kernel panics are exceedingly rare on windows. i havent BSOD'd in eons

yes I mentioned tmux as a project management/switcher tool what about it? (how good (nvim) is with tmux and the low low memory usage.

I haven't had a kernel panic once on reliable hardware. Linux is way more stable than windows device drivers and progressively less reliable graphics drivers.

"Who said anything about tmux?"

"yes I mentioned tmux as"

lol. good day

Kernel panics are almost entirely about bad RAM on all systems today. But last time I was stuck on Windows, about 2017ish, I was suffering constantly from blue screens in a way that never triggered on linux.

> kernel panics are part of life with consumer hardware.

This isn't right. It was certainly true in the nineties, but I haven't seen one in years on Windows and I spend many hours a day in it both for work and play.

DDR5 where yields are pushed with module level ECC? Janky amd gpu drivers, "RGB" controller drivers misbehaving, some hardware that is just as bad as it was in the 90's since they all use driver sourcecode copied from the 90s.