Live data from Hacker News

WSL2 corrupting Git repositories and shell history

github.com

151–160 of 423 posts

Re: WSL2 corrupting Git repositories and shell history

#151

Earlier quoted context omitted.

Enabling hardware virtualisation opens up a significant and deep attack surface. Considering the vanishingly small percentage of users which benefit from it, I hope it stays off by default.

Windows is moving to a model where Windows itself is run as a virtualized OS. I believe this is enabled by default in new installs. So having a Linux VM in Hyper-V isn't opening up much new attack surface.

It's not enabled by default. Enabling Hyper-V still causes a battery/performance hit that is going to be hard to get rid of.

Re: WSL2 corrupting Git repositories and shell history

#152
post #87

Earlier quoted context omitted.

SSH and X Windows servers also exist for Windows.

It takes me 2 minutes to install WSL Ubuntu. Or I could spend half a day on figuring out a hacky solution to a Windows/SSH/XWindows workflow that offers even a comparable level of integration. It will grow into weeks of obsessive tweaking until I feel compelled to write a blog post for HN where I show my sick setup and hours and hours I dumped into this, while meaningful work piled up in my TODOs. ... Or I could just…

Or just install Humming Bird, working just fine for me since 2000.

Re: WSL2 corrupting Git repositories and shell history

#153

Earlier quoted context omitted.

>Clipboard works perfectly Which one? Secondary? And the primary does not work at all?

The Windows clipboard just works, because WSL2 terminals are just regular Windows apps.

At this point - Can't you just SSH into the local linux VM or a remote linux server?

Re: WSL2 corrupting Git repositories and shell history

#154
post #108
post #105

Earlier quoted context omitted.

Other than the startup time (mitigated by starting the VM right after startup) I have no issues with virtualbox. File mounts, copy & paste... everything works more or less fine. WSL, on the other hand, has been nothing but trouble.

One downside there is the constantly huge RAM consumption of such a setup. EDIT: At least compared to WSL1. However WSL2 also has some advantages in that it can reclaim unused memory and suspend the VM when not in use.

Why would VM-based WSL2 use any less RAM?

Re: WSL2 corrupting Git repositories and shell history

#155
post #67
post #45

Earlier quoted context omitted.

Business. For better or worse, there are plenty of places where the policy and tech allow WSL but installing a hypervisor on your machine is much more challenging. WSL2 is basically just a Linux VM, though (I think it actually uses Hyper-V containers which seem to occupy some weird space between Linux container and VMs)

Hyper-V is VMs not containers. When you enable Hyper-V it's actually the 'operating system' and Windows is a guest VM believe it or not.

This is how every type 1 hypervisor works.

https://en.wikipedia.org/wiki/Hypervisor

Re: WSL2 corrupting Git repositories and shell history

#156
post #30

I think calling it WSL2 was a mistake. 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. 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 l…

File system corruption is unforgivable mistake, but FS work is really hard to get right. Even stuff like VMware corrupts shared folders ... wherever they try to bypass a driver translation layer. Just Google for “vmware shared folder corruption”

My experience was locked files or lost shared folders (VM doesn't see them until you say the magic words, aka randomly stop and start services until it works). Both happened so (relatively) frequently that I just lost confidence in the feature until version 16 where read-only folders works fine. (I stopped using it in version 9)

Re: WSL2 corrupting Git repositories and shell history

#157

> Feel like booting Linux on a separate disk because of these issues. 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 ?

This is why I like macOS so much. I understand that it's not the same as having Ubuntu in WSL, but using the Mac terminal is so close to the experience I have when I SSH into my Ubuntu box that it's nearly 1:1 for me.

Oh, blessed are those who never had to deal with the assumption that every shell is bash despite using /bin/sh in shebangs of their scripts, or with the assumption that all core utilities (like find or grep) are of the GNU flavor.

Ignorant they are, yet their ignorance is a bliss.

Re: WSL2 corrupting Git repositories and shell history

#158
post #126
post #76

Earlier quoted context omitted.

True, but if MS hadn't presented WSL2 as a variant of WSL, any issues fixed in WSL2 wouldn't count as fixed in the WSL issue tracker. I would prefer it if their issue tracker marked these, more honestly in my opinion, as "This issue is will not be fixed in WSL, you can migrate to HVL instead" (using HVL as a hypothetical name for WSL2) with a separate HVL issue tracker.

I guess I don't follow your point. The very reason WSL2 exists is because there were countless issues that COULDN'T be fixed with the way WSL1 was implemented. Why would they leave an issue open they fixed, just because the fix required a complete re-implementation? Furthermore why would they change the name, this is literally how they are carrying forward the functionality of WSL 1. It's still Linux on Windows, ther…

They aren't carrying forward the functionality of WSL1. Yes, there are issues that cannot be fixed in WSL1. There are also issues that aren't, and quite likely can't be, fixed in WSL2, that do work in WSL1. The file system corruption that happens here in WSL2 is a nice example, it is something that could not possibly ever happen with WSL1 because of the way it was designed. WSL2 is not and will never be a full replacement for WSL1; WSL1 and WSL2 are two separate products, both with their own advantages and disadvantages, and I wish Microsoft would treat them as such.

> Should Mac Office not be called Office because they completely re-wrote it?

I do not know how different Office for Windows and Office for Mac are, but to go with a different example, yes, I do think Visual Studio for Mac and Visual Studio Code should not have carried the Visual Studio name, it causes unnecessary confusion.

Re: WSL2 corrupting Git repositories and shell history

#159

Earlier quoted context omitted.

Yeah I think you nailed it there actually. That's exactly their modus operandi. What's even worse is they have managed to abstract most of the support away in this cycle. You can't get enterprise support now because they gutted that entirely. You can't get them to do anything on github because they keep moving all the projects around and erasing them all or auto closing the tickets and no one on first line support kn…

> Yeah I think you nailed it there actually. That's exactly their modus operandi. They're following the "rules" from "The Cathedral and the Bazaar", remember. Specifically, the "Release early and often" bit, for the purposes of this conversation. Microsoft are considered "good open source citizens" because of the changes they've made to follow the written non-rules as well as the the unwritten rules. If you're going…

I think Microsoft gets more shit exactly because people expect more of them. They are the giants. they aren't a scrappy startup that needs to release or go bankrupt.

Microsoft are seen as the safe choice, so their stuff has to "just work".

That's obviously a bad place for innovation within Microsoft, but i don't really think anyone cares about the future of Microsoft.

Re: WSL2 corrupting Git repositories and shell history

#160

Earlier quoted context omitted.

FS corruption is the worst as you lose total confidence in the product. This is a mega process escape that the WSL team would need to transparently detail why it happened, what the remedy is, and why it'll never, ever happen again.

My guess is it's the result of shutting down the virtual machine that runs the Linux kernel too soon, leaving writes to the virtual hard disk in an inconsistent state. This coincides with "shutdown /r /t 0" being able to cause it as well as blue screens or power loss. And explains why I've never seen it, despite using WSL2 on insider preview builds on multiple machines daily: I almost never shut down, only for update…

The kernel should and can handle unexpected ahutdowns without corruption. Data loss sometimes, but not corruption.
Post reply on HN