zlacker

>>tonyst+(OP)
We burned an evening just last week tracing an Intel wifi driver issue to missing kernel headers that required upgrading the kernel to a new, non-LTS version. And only then did we move on to Nvidia drivers.

So no, still not the year of Linux on the desktop. Our entire dev team does it, but largely because Nvidia and Apple stopped working together.

The bigger surprise is Windows WSL2 is just about there for Ubuntu support. We are just blocked on opencl side of Nvidia support (but no ETA.)

>>lmeyer+19
I really tried to make wsl work for the windows users on my team, but we kept getting tangled up with networking (I guess there's a virtual switch involved and so when a tool claims to have forwarded a port it's hard to figure out where it forwarded it to and why only half of your stuff can see it).

Do you know if that situation has improved in the last year or so?

>>__Matr+mj
I'd like to know on your use case more, if possible. Not sure I've ever need to forward port or I probably read your description wrong way.

>>CoolCo+Io
It's been a year but if I recall it went something like this:

I was using microk8s (a kubernetes distribution) on the wsl side, and I had python scripts (also on the wsl side) which would deploy things into it, run tests until there was a problem, forward a port from the broken service to "localhost:8080", and then instruct the user to open a browser to explore the UI post-test-failure.

On bare metal Linux this was no big deal because "localhost" was unambiguous. But on windows you end up with the browser on the windows side and the forwarded port on the wsl side, so when the browser opened there was nothing at "localhost:8080" even though I could "curl localhost:8080" from the wsl side and get a response.

Presumably there is a way to further forward the port so that it is available to both Windows browsers and wsl python scripts, but I never found it.