Live data from Hacker News

WSL2 corrupting Git repositories and shell history

github.com

241–250 of 423 posts

Re: WSL2 corrupting Git repositories and shell history

#241

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 b…

Opposite anecdata - I got a gaming PC and i migrated all my development to it and WSL(2) has been a godsend. VS Code has a "WSL Remote" mode that works really well (where a vscode server runs in Linux and the windows GUI access it "remotely"). I even use the Windows Github app for the occasional GUI-assisted commit, and apart from being slow its fine.

I've had only two problems with this set up:

- Occasionally VS Code Typescript features slow down, but it fixes itself a few days later (maybe after a restart). I presume this is due to the WSL Remote, but not certain.

- The occasional line endings snafu, but this is more of a tooling issue.

Re: WSL2 corrupting Git repositories and shell history

#242
post #69

Earlier quoted context omitted.

I don't think calling it WSL2 was a mistake. It wasn't something that was good for the users, but it had a very clear benefit for the people working on WSL: calling it WSL2 allowed them to close WSL1 issues en masse as "fixed in WSL2" and never look at them again.

Did they really do that? MS's official line is that WSL is not deprecated, and can be run alongside WSL2.

Yes they did.

We discussed this here before: I am reasonably certain -- without having any insider info -- it was various ptrace types which broke the camel's back besides the abhorrent file system performance. Both PTRACE_SEIZE and PTRACE_TRACEME was closed as fixed-in-wsl2 https://github.com/microsoft/WSL/issues/2028 https://github.com/microsoft/WSL/issues/3031

Re: WSL2 corrupting Git repositories and shell history

#243
post #4

Earlier quoted context omitted.

But why? WSL1 was something like wine but reverse, but WSL2 is actually linux.

FreeBSD has native support for Linux binaries by mapping system calls, and it's fairly reliable when it works. What's nice is that when it works, it works, adding support for system calls improves coverage, and since underlying things like the FS aren't virtualized, it tends to be pretty reliable.

Yeah; Windows had something like that, too. It was WSL1 (or just "WSL"). I also tend to think that was the better approach.

Re: WSL2 corrupting Git repositories and shell history

#244

Earlier quoted context omitted.

I develop Rails in WSL1 just fine. > Postgres never worked for example natively. That's a minor incovenience at worst. I will stay put in WSL1. If I wished a VM I would have just installed VMWare and run some Linux ISO image from it.

> That's a minor incovenience at worst. What a bizarre claim. It's irrelevant if you don't need Postgres, a minor inconvenience if you can easily adopt a workaround, and a show stopper if you were relying on accessing a local Postgres instance.

Can't you just run Postgres natively on Windows? It's a database, you can talk to it from WSL over a local socket, no?

Re: WSL2 corrupting Git repositories and shell history

#245
post #236

Earlier quoted context omitted.

Is WSL really so buggy? I never got that impression myself. All my problems with things getting fussy have been on WSL2.

I tried to build two projects in WSL1, one using the Z3 theorem prover, and one using Chrome for scraping. Both ran into kernel issues. So for me it failed about 100% of the time on anything non-trivial.

Chrome uses almost every single Linux syscall under the sun. So I guess that's not too surprising.

I am a little surprised that Z3 had difficulties. I did not think it used anything exotic.

Re: WSL2 corrupting Git repositories and shell history

#246

Earlier quoted context omitted.

This is probably HyperV. I’ve seen exactly this ext4 corruption in production on windows server 2012R2 with CentOS 7. Even to the point that the machine remounts root read only. Unfortunately our windows operations guys are severely lacking in diagnostic savvy and just reboot the machine over and over again or blast it and provision a new one and don’t analyse the problem. From what I’ve seen it’s a combination of th…

After upgrading to WSL2, I started having issues with a Virtualbox VM. Turns out it didn't play nicely with HyperV. I went back to WSL1.

That’s because HyperV is a type 1 hypervisor and vbox is a type 2 hypervisor. They don’t mix well :)

Best option is still vbox and putty IMHO. VScode will work with it and SSH fine.

Or say fuck it, buy a Mac and do all your Linux work in the cloud.

Re: WSL2 corrupting Git repositories and shell history

#247

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 b…

Opposite anecdata - I got a gaming PC and i migrated all my development to it and WSL(2) has been a godsend. VS Code has a "WSL Remote" mode that works really well (where a vscode server runs in Linux and the windows GUI access it "remotely"). I even use the Windows Github app for the occasional GUI-assisted commit, and apart from being slow its fine. I've had only two problems with this set up: - Occasionally VS Cod…

[deleted]

Re: WSL2 corrupting Git repositories and shell history

#248
post #104

Earlier quoted context omitted.

The web version of Outlook has come a long way, and in my opinion has become the superior product (for my use cases, at least).

You’re also missing Adobe products as well as most games. Using Linux without a reboot is an incredible convenience. Glossing over the value of proprietary software that only runs on Windows is narrow minded.

My comment was really only about Outlook itself (using the web vs the desktop version, I prefer the web version).

that said, I hate Adobe products with a passion. When I build identical computers for my wife and I, the moment I install the Abode shit on hers, it becomes noticeably slower at everything. I don't truly understand it.

Re: WSL2 corrupting Git repositories and shell history

#249
post #42

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…

Huh, I had the opposite experience trying to use wsl1 with a rails app, which required lots of workarounds. Postgres never worked for example natively. Several npm modules would fail when running webpack. wsl2 worked perfectly for these cases. I wonder if people are mounting an ntfs volume in wsl2 which is really slow and janky?

> Postgres never worked for example natively

We (postgres) did fix an ENOSYS (missing syscall) problem at some point so WSL could run Postgres. The surprising thing for me was how long it took for anyone to tell us it was broken/spewing warnings. That was forced when we changed a warning to a panic.

Re: WSL2 corrupting Git repositories and shell history

#250
post #245
post #236

Earlier quoted context omitted.

I tried to build two projects in WSL1, one using the Z3 theorem prover, and one using Chrome for scraping. Both ran into kernel issues. So for me it failed about 100% of the time on anything non-trivial.

Chrome uses almost every single Linux syscall under the sun. So I guess that's not too surprising. I am a little surprised that Z3 had difficulties. I did not think it used anything exotic.

Z3 had a timer to stop the solve if it takes to long and that used a specific option of clock_gettime that wasn't supported. I hacked around this and it otherwise worked fine.
Post reply on HN