On my current development workstation[0] I have tried almost all major operating systems, from macOS (i.e. a Hackintosh) to illumos. As a desktop environment all are terrible. Considering my hardware and peripherals, I've never really had too much of a problem with Linux, my default choice for the last decade and my current target deployment platform, but it turns out that even when running a Hackintosh, everything is just better. This isn't to say that there aren't some things that Linux is better at even on the desktop, but generally no single environment really satisfies me, and in fact generally annoys me with bugs, bad performance and inconsistencies.
Recently I tried WSL2 again. The landscape has changed over the years and
I've found that the latest state of things in Windows 10 actually works
out quite nicely for me. When I'm developing outside of a browser I don't
stray too far from the terminal, so when I'm running Vim and my
development tools inside tmux, it's just Linux. I get the exact same
experience as I would on Ubuntu, but my bluetooth earbuds, my webcam and
hardware acceleration just work and really well too. In a typical day I
don't need to cross the file-system boundary and when I do it's either
because I'm running a background backup job with rsync in Linux
transferring files to an NTFS formatted external USB drive or I'm viewing
Linux-hosted content in Chrome/Firefox/Edge on Windows. TCP port
forwarding is handled transparently and for local files you can use the
//wsl$ network mount, in either case I haven't noticed any
performance issues at all. Once I had set up everything, there were two
missing pieces left.
In my experience both macOS and Windows have terrible out of the box
support for custom hotkeys. I tend to use keyboards that don't have any
kind of dedicated multimedia keys or function key modifiers, or if they
do, require you to do some kind of finger gymnastics to invoke them. This
is why I have my own scheme that I
can setup as needed anywhere. On pretty much every other operating system,
because of X, this is trivial. Either the desktop environment has an
interface or a configuration file you can use to define your hotkeys.
Alternatively you can use a more generic solution such as
xbindkeys. Wayland clients also have their own
implementations. The last time I tried Windows, I used
Microsoft PowerToys, but aside from including lots
of other stuff that I didn't need, there
were certain limitations that I came up against, such as the inability to
define a 4-key binding, which for my scheme at least, is a requirement.
I've now settled on AutoHotKey, an application I had never used but had heard about and which addresses the requirement perfectly, here's my current configuration:
^!N::Media_Previous
^!n::Media_Next
^!p::Media_Play_Pause
^!y::Volume_Down
^!u::Volume_Up
^!t::Run, ubuntu.exe
You just enter this into a file ending .ahk, create a
shortcut to that file and place it in the startup folder (Win +
R shell:startup).
The other small missing piece was a shared clipboard between Windows and
Linux. Now, you can of course copy and paste in a terminal window, whether
running WSL via cmd, PowerShell,
Alacritty or others,
but what I was missing specifically is the ability to pipe in and out of
the clipboard on the command line. So what you get with
xclip or xsel on X or pbcopy/pbpaste
on macs.
On Linux my tmux config includes these lines:
set-option -g mouse on
set-option -s set-clipboard off
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "xclip -se ci -i"
It basically allows you to select with the mouse (or using keybindigs with
vi mode enabled) and copy into the clipboard the selection you've made.
It's a small feature but for me a massive productivity boost and something
I use all the time, so without xclip or similar on Windows I
missed it.
I already knew that you could refer to .exes in WSL and it
would interact with the application on the Windows side[1], so
I began investigating the Win32 C APIs required to do this
programmatically[2] but after a quick search I found out about
clip.exe
which is the native out of the box solution to xclip. I made
a very simple tweak to my config:
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "clip.exe"…and everything just works as expected.
0 a refurbished HP Elite Ivy Bridge system with a load of
extra RAM.
1 as an example, instead of xdg-open . that I
use regularly for opening the current directory in the file explorer,
you can do explorer.exe ..
2 I'm comfortable with C but totally unfamiliar with Win32. I
also considered cross-platform solutions in Rust or Go.