Live data from Hacker News

WSL2 corrupting Git repositories and shell history

github.com

181–190 of 423 posts

Re: WSL2 corrupting Git repositories and shell history

#181
post #108

Earlier quoted context omitted.

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?

WSL VMs are gen2 (fully paravirtual) hyper-v VMs, so use dynamic memory allocation. VirtualBox, even with Hyper-V as its engine, doesn't do this. I don't think any standalone Linux distros offer a standalone Hyper-V paravirtual image that is not a WSL2 image.

Re: WSL2 corrupting Git repositories and shell history

#182
post #35

Earlier quoted context omitted.

Yes, let's pretend that the 4.19 EXT4 corruption issue in 2018 never happened.

No need to pretend, because it never happened: > Initially, the problem was thought to be in the ext4 filesystem, since that is what the affected users were using...It took until December 4 for Lukáš Krejčí to correctly bisect the problem down to a block-layer change. https://lwn.net/Articles/774440/

I never said the problem was in the EXT4 filesystem. The problem resulted in EXT4 corruption.

Quite sure the Git corruption issue WSL2 has isn't in Git either.

Re: WSL2 corrupting Git repositories and shell history

#183

Earlier quoted context omitted.

I use a mix of WSL2, and VMs. WSL2 has a few nice properties for some use cases: a) It comes default with some network binding magic (ok, just configuration) that makes your WSL env almost actually behave like localhost. I know you can configure this yourself, but it's nice out of the box. (on the other hand, sometimes is this exactly the opposite of what you want...) b) My main machine is a bit RAM constrained, and…

Also, I think WSL2 is currently only way to access GPU through Cuda API from the guest linux.

Hyper-V can also do PCI pass-through if you have a compute card to assign to the guest. If you're just running the one card, though, you need WSL2 to handle the sharing.

Re: WSL2 corrupting Git repositories and shell history

#184
post #35

Earlier quoted context omitted.

Yes, let's pretend that the 4.19 EXT4 corruption issue in 2018 never happened.

No need to pretend, because it never happened: > Initially, the problem was thought to be in the ext4 filesystem, since that is what the affected users were using...It took until December 4 for Lukáš Krejčí to correctly bisect the problem down to a block-layer change. https://lwn.net/Articles/774440/

OK, the 4.19 filesystem corruption issue.

The fact that it was in the block layer doesn't exactly mean it didn't materialize as a FS corruption issue.

Re: WSL2 corrupting Git repositories and shell history

#185
post #177

Earlier quoted context omitted.

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

This is data loss. A few object files in the Git directory are truncated. Which results in a corrupted repository, from Git's point of view.

That’s corruption. Data loss would indicate an entire fs transaction getting dropped entirely - but not breaking the principle of atomic ops. A write should either happen entirely or not at all.

Re: WSL2 corrupting Git repositories and shell history

#186

Earlier quoted context omitted.

Also, I think WSL2 is currently only way to access GPU through Cuda API from the guest linux.

Hyper-V can also do PCI pass-through if you have a compute card to assign to the guest. If you're just running the one card, though, you need WSL2 to handle the sharing.

Additionally Win Pro is needed for Hyper-V, while WSL2 can be used in lower level Win versions.

Re: WSL2 corrupting Git repositories and shell history

#187
post #98

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.

I mean, why not do that? I tried WSL because I thought it would be faster than a heavyweight VM. Turned out it's dog slow in comparison. Honestly don't see a use for it.

WSL1 is much better integrated, which is useful for some things, especially when networking is involved. And it wastes less memory as a consequence.

The root partition is slower, but I'm usually manipulating windows files anyway so both versions are similarly slow.

I use WSL2 right now, but only because I need to mount a vhd that's formatted with BTRFS.

Re: WSL2 corrupting Git repositories and shell history

#188

> 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 ?

> What am I missing ? Visual Studio. The other thing on my Windows VM is Affinity Photo/Designer (because GIMP is not a realistic Photoshop alternative).

I'd buy affinity designer, photo and publisher again if they ship a Linux version. I have it both for Windows and Mac.

Re: WSL2 corrupting Git repositories and shell history

#189
post #144

Earlier quoted context omitted.

Office, which doesn’t have a good replacement on the web or on Linux.

What is inadequate about Libre Office ?

Calc is really not an adequate substitute for Excel if you need to use VBA macros - which might be coming from your customers! And in the wild I see plenty of older Excel documents (before 97) which I don’t think are compatible with LibreOffice. Obviously this isn’t an ideal situation but historical data around prices/etc from the 90s are often stored as old Excel binaries.

In general I think using Calc (or Google Sheets) instead of Excel is a bad idea for a business. Word processing and spreadsheets - sure (although there might be some things specific to Word/PPT that I am not aware of). But Excel is a very specific piece of software and should not be thought of as a general “spreadsheet tool.”

Re: WSL2 corrupting Git repositories and shell history

#190
post #172
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.

Was that incorrect somehow? WSL2 fixed a ton of issues for me.

It's a true statement but it's quite unhelpful to tell people that a problem they have is fixed in a different semi-compatible piece of software.
Post reply on HN