Live data from Hacker News

WSL2 corrupting Git repositories and shell history

github.com

91–100 of 423 posts

Re: WSL2 corrupting Git repositories and shell history

#93
post #44

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…

I was using WSL to do esp8266 development so I could use linux tools. The official esp8266 windows toolchain is based on cygwin. If I'm using something that needs a unix environment anyway, why use cygwin when you have WSL? I upgraded to WSL2 because well 2 is bigger than 1 so it must be better. But no, nothing worked. Serial ports are not supported in WSL2.

> why use cygwin when you have WSL?

Well. Has cygwin ever corrupted get repos?

Re: WSL2 corrupting Git repositories and shell history

#94

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

I need to use Windows for Visual Studio, Unity Editor and other things targeting Windows, but I've been a Linux person for 14 years now and would like to still do as much as possible via the tools I'm used to.

Re: WSL2 corrupting Git repositories and shell history

#95
post #81

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…

Had a serious talk a Unix manager over a decade ago who was convinced Windows ops didn't require as much expertise as Unix/Linux. It was a common misconception that MS seemed to encourage. As someone who came over from Windows, I knew better. That attitude continues to influence standard practices, hiring and, most importantly, training and education opportunities for Windows admins -- to the detriment of all. I've a…

Agreed. I've done both and if you ask me Windows ops is vastly more difficult because everything is brittle, inconsistent and unreliable and rarely repeatable almost all of the time. It requires great skill, determination and persistence to navigate issues like this. Unfortunately as you suggest, the outcome is hiring as cheap as possible and fixing all issues by not changing anything other than replacing everything every few years. There is rarely any day to day admin I see other than planning the next major rollout with some vain hope it'll have less problems than the last one.

Re: WSL2 corrupting Git repositories and shell history

#96

Earlier quoted context omitted.

If you drop WSL then you get confused branding of what they are. WSL1 and WSL2 make it pretty clear you're getting the Hyper-V thing for the latter and the former is a Linux sys call API layer. I'm actually surprised they can't be used together.

Those names don't imply anything about their implementation.

Tangent: they imply running on Linux; a Wine substitute.

Re: WSL2 corrupting Git repositories and shell history

#98
post #42

Earlier quoted context omitted.

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?

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.

Re: WSL2 corrupting Git repositories and shell history

#99
post #81

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…

Had a serious talk a Unix manager over a decade ago who was convinced Windows ops didn't require as much expertise as Unix/Linux. It was a common misconception that MS seemed to encourage. As someone who came over from Windows, I knew better. That attitude continues to influence standard practices, hiring and, most importantly, training and education opportunities for Windows admins -- to the detriment of all. I've a…

MCSE was a punchline 20 years ago so this is a misconception almost as old as the entire profession of Windows Admins.

Re: WSL2 corrupting Git repositories and shell history

#100
post #42

Earlier quoted context omitted.

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?

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 incnvenience at worst.

The level of inconvenience purely depends on your stack and how its developed. Often things which don't bother me have huge effects on other members of my team, or on people working on other projects.

Post reply on HN