3 ms·
Don't get me wrong -- I'm not complaining! Like I said, improvements are just that: an improvement. And my priorities aren't the same as WSL2 priorities, that's
by nbadg 3y ago
Don't get me wrong -- I'm not complaining! Like I said, improvements are just that: an improvement. And my priorities aren't the same as WSL2 priorities, that's clear too.
But I don't think it's reasonable to expect that all of my tooling work with WSL2. A decent chunk of my tooling isn't even developer-centric -- why would the tools I use for asset creation support WSL2? Should Adobe? Should Inkscape? What about the docker sync that I use for static assets, or for source code when I need to move between laptop and desktop and don't want to make a temporary commit or patch with git? Windows app development is already messy enough, are we going to require that everyone making a windows app jump through yet another hurdle, on the off-chance that the small percentage of windows users who happen to be devs can get it to work with docker containers? That doesn't seem reasonable to me.
There are plenty of people like me that choose to develop on windows (and aren't forced by a company to do so), precisely because they want to be able to use windows as they normally would, but also, yknow, develop code. All I'm saying is, having a native way to mirror a filesystem while providing the expected semantics on both sides of the share seems like an important feature for these kinds of workflows.
- pletnes 3y agoI see your point, but only partially. Why can’t you write code on windows today? I can, for some/most projects. Why do you then want WSL?
- nbadg 3y agoWhether or not you can develop the code directly on a windows host is highly dependent on what kind of code you're writing, and what environment it's being deployed to. It's the recommended way to do virtualization these days on Windows, and if you develop using docker, you have to use WSL. Even in cross-platform interpreted languages like python, if you have third-party deps, not all of them are available on windows, nor do they always work there. Basically, if you're deploying to a linux server but developing on the windows host machine, it's not a question of "if", but "when" you'll run into a problem, etc etc etc. And this is just the "easy" case, where everything is theoretically cross-platform; when you start getting into things that involve proprietary compiler toolchains or specific hardware targets, you don't always have a choice what platform you work on at all. Put more directly: I don't think any of my previous employers would have had a problem with me developing on a windows machine, as long as I was running the code in a virtualized environment that matched production. But it wouldn't have been acceptable at any of them to run the code directly on the host.