WSL2 was promised as a good working extension for a Linux dev environment on windows by my peers. Sadly, a whole host of issues specific to my dev environment meant that it was useless as I’d spend more time fixing it than getting any valuable use out of it. More importantly, this became the very reason I switched to arch full time, and haven’t looked back since. I still hope that it becomes what it was promised to be, although I don’t see myself going back to windows any time soon.
After constantly getting caught in bugs between WSL and Docker, i'm now running Ubuntu Server headless with a Windows VM (with GPU passthrough) on top.<p>The biggest issue across all these things is filesystems. There is simply no good way to share a filesystem between Windows and Linux that is both 1. fast 2. fully correct - i.e doesn't break some code.<p>SMB/NFS just never work super well because they are slow, or programs think they are local filesystems so things break (e.g VScode won't detect new files created on the linux side of a SMB mount without a manual refresh). Plenty of details on getting permissions right too. Not to mention extended attributes which differ slightly and break stuff. Network file systems in general are just too different to local FS's for programs to work seamlessly.<p>The 2 non-ideal solutions I've found are 1. keep all files in linux + edit over network using VSCode Remote or IntelliJ Remote support or 2. keep a copy of the dev workspace in windows, and use something like unison (or manual git) to sync.
While we're on the topic of WSL2 causing issues, I will add one that I noted to the pile. If you have WSL2 installed then the first bash on PATH is the WSL2 version of bash. For whatever reason, this version of bash has a major impedance mismatch with Emacs and org-mode. From windows native Emacs (not an Emacs installed in WSL2) if you try to run an org babel block that contains bash code, whole commands will simply be ignored. The end result is that if you blindly execute bash blocks in Emacs on windows without checking which bash is being used there can be disastrous results because a seemingly safe script like `pushd some-folder; rm -r <i>; popd` suddenly becomes `rm -r </i>` without warning. I'm guessing that it has to do with mismatched line endings since mingw bash (aka git bash) doesn't have these issues. Also, you can't rely on the ordering of your PATH environment variable to protect you because updates can change it.<p>tl;dr WSL2 bash is not bash but it pretends to be and there are terrifying changes to the semantics of bash scripts as a result.
WSL2 works until you need it really, and then it starts giving you problems. The networking problems are the worst. Installed a Linux VM under VMWare and called it a day.
Reading through the issues it seems like the problem is occuring when opening the same files from directly inside the WSL2 container and also through the network device that exposes them to Windows at the same time. I'm not very familiar with how WSL2 exposes files but that seems to be the problem
I think calling it WSL2 was a mistake.<p>The predecessor, WSL, "just worked" and it was more a less a linux experience for most practical purposes-- and certainly better than hoary old cygwin.<p>This caused a lot of people to believe they could just transition to WSL2, lead on by the promise of an even more performant linux experience. The documentation didn't say anything about complications from attempting this, so a lot of people just tried it as soon as they could, thinking it would go as smoothly as when they tried WSL. But nope... it many cases, it doesn't just work out of the box. There's network configuration and gateway issues, snags with vpn, and now this git repo corruption. When you look on git issues, it's just people randomly shot-gunning suggestions, some of which work, some of which don't. I think WSL2 was rushed out too early, or at least it's lacking a comprehensive troubleshooting guide to get it up and running.
I won't leave WSL1 for my bash on Windows needs.<p>For native linux, I have my choice of distro installed on my choice of hypervisor (Debian, VMWare).<p>I use VSCode and the Remote SSH extension (functions identically to WSL2). The difference is I know exactly what is going on. I know when and why certain network conditions exist (port forwarding, etc).
I only use Windows because of a couple of tools there is no equivalent version for Linux. Unfortunately companies think there would be not enough customers to warrant development for that OS so I am kind of stuck with maintaining dedicated Windows PC. I have mixed feelings about Microsoft appropriation of Linux. Whatever they touch turns to excrement with a few exceptions.
Problem found, added sync() before shutdown.
<a href="https://github.com/microsoft/WSL2-Linux-Kernel/issues/168#issuecomment-754856054" rel="nofollow">https://github.com/microsoft/WSL2-Linux-Kernel/issues/168#is...</a>
I experienced this problem and a ext4 corruption, too. Because my company force me to use Windows for internal policy, my previous solution was a VMware VM , accessed "remotely" by my IDE. Then I wanted try the new sauce. My colleagues working to legacy code on SVN also experienced problems (anyone else ?). So I switched back to VMWare VM. The other considerations were that a VM can be easily backupped copying a directory and, if I need to change computer or an additional environment, the migration of the whole environment is extremely easy. Moreover i use snapshots, so if something goes wrong at OS level I can go back with a click.
Important I think to point out that these are (numerous) user reports of files "corrupted". There isn't afaics any confirmation yet as to exactly what's happening nor the underlying cause.
I will need to monitor this more closely. I have switched to a WIN/WSL2 setup recently from Mac and have not had this problem happen to me.<p>Nonetheless I hope this gets fixed before it hits me.
A while back spent about 2 mos mastering WSL2 and came to the conclusion that the default of automatically opening up in the Windows fs share was... unwise. Besides fs permissions being a complete mess, the unstable behavior described here liked to show up at the most inopportune moments. Wound up confining my work to the virtual Linux fs, but that kind of defeated the whole purpose of WSL for me. I'm also back to using a VMware machine on my company owned laptop, but my personal systems are still Linux on bare metal. As an aside, I struggled with Hyper V to replace VMware, but it makes the system unstable on the particular Win 10 builds my company provides employees. I'd gone at least 8 years not seeing a blue screen before that.
While using Visual Studio (not code) with git in wsl2 with Ubuntu 20.04, I saved three open files with changes, committed shutdown the laptop. On next start files showed as empty 0 bytes in Visual Studio and thought as far as I recall were non-zero size in wls2. No way to recover them from git. I stopped using git repos in wls2 for now.
Since there’s almost always comments from people saying how they’re happy on Windows whenever there’s news about some fuckup on macOS, I’d like to balance it by saying that shit like this is why I’m never going back to Windows.
I only see 1 user confirming it and he had a special or odd disk setup (merged disks which also do not show as merged, might be the source of the problem).<p>Is this confirmed by anyone else?
I was afraid that WSL2 was old Microsoft's EEE again.<p>Thanks for keeping it so bad that you can't even push to a repo without corrupting the filesystem or the repo itself.<p>It might have supposed to be EEE, but it turned out to be the last push many people needed to switch to a full Linux OS.
Reminded me of a different issue:<p>If you have 2 different git clients (different git versions) accessing the same shared .git directory, bad things can happen -- incorrect file status, iirc.
I used WSL2 with Debian and found it slow, aside from that Windows required what seems like an excessive amount of system resources to even get to WSL2.
Another funny interaction I found with WSL2 and Windows is file case sensitivity leading to all sorts of weird error messages<p>I wish I can use a real Linux installation but their display drivers don't work well with my multiple displays with different resolutions
> Feel like booting Linux on a separate disk because of these issues.<p>It always seemed strange to me that people would rather use WSL than the real thing when Windows doesn't bring much advantage. What am I missing ?
I don't really understand the use case for WSL. What are the advantages? You could run a full Linux VM and do everything on it on any machine these days. Which is what I do, but I'm just an old school hack. Anyone who uses WSL care to enlighten me? Thanks!
> Mind that I come from a Ubuntu distro, Windows is the most energy efficient solution at the moment and allows me to run my Dev tools and work on battery for 4 hours straight. Ubuntu (or any Debian-based distro) destroy my battery in 40 minutes and there's no solution or optimization for that.<p>I know this is not a solution, but the Librem laptops from Purism hold up for hours straight. I also used to run Windows on laptops for the same reason, but the obvious solution to this is to buy a laptop built with Linux in mind from the ground up, and now we have options available.
Jfc that’s some janky shit many of you seem to be into.<p>I don’t quite get why some developers seem hell bent on those kinds of hybrid development environments. Why not straight up Linux or macOS where he user-space is consistent at least?
Reminds me of this e-mail chain at Microsoft, on September 27, 1991:<p>Brad Silverberg: "drdos has problems running windows today, and I assume will have more problems in the future."<p>Jim Allchin: "You should make sure it has problems in the future. :-)"
The fact that this can even happen is enough for me to never touch this for doing work.<p>I stopped developing on Windows after the Windows 8 fiasco and I don't see myself ever coming back.<p>Both Mac and Linux are faster, more convenient, and more solid in my experience.<p>I considered advising my son to buy a Surface for his school work and developing on WSL2, but I'm glad the M1 Mac came out with a much better cost/performance, so he got one. At least his git repos won't get corrupted.