Hacker News Reader

Comment by awestroke | Hacker News Reader

Windows files are still available via /mnt/c on WSL2

As WSL1 runs on the same kernel I have stuff like named pipes available. I can fully mix processes from both worlds in one workflow. _Some_ of that works with WSL2 as well, but as it's processes on two different kernels requires hidden workarounds to make that work - and not everything is working (and may be even possible).

Why would you want to mix Windows and Linux processes into one workflow on the same host?

I’m sure you’ve encountered a very niche problem that requires it, but I cannot think of any scenario where that kind of behaviour would be desirable vs splitting those workflows up.

Are you not able to have separate Windows and Linux hosts (eg VMs or containers) that are instigated to run in parallel as part of the same pipeline, but don’t rely on the same processes running in the same host?

Or at the very worst, use a TCP/IP based RPC to share state between the different hosts?

We're using OBS for building stuff (and heavily abuse it for the Linux side already) - a few things (like reverse dependency builds) make that more useful that most of the other stuff out there on complex projects. So when the requirement for some Windows builds came along (which are tiny compared to all the other stuff we're doing) we just ended up using WSL to have Windows workers in OBS. Also has some other advantages with how our cmake builds work (short version, developers can do their own bit in visual studio, and then a bit more checks run on CI where we can reuse the usual stuff without caring about Windows)

What’s OBS? I’ve only seen it in reference to the video streaming (et al) tool. Guessing that’s not why you’re talking about here though?

The Opensuse Build System. It's pretty good at figuring out if something needs rebuilding, so in some cases violating it and making it do stuff it's not supposed to is a sensible choice.

Reply on news.ycombinator.com