Live data from Hacker News

Windows Subsystem for Linux 2 Moving into General Availability

infoq.com

331–340 of 420 posts

Re: Windows Subsystem for Linux 2 Moving into General Availability

#331
post #250

In WSL1, running "wsl git status" on a moderately sized repo on an NTFS (Windows side) drive or SMB file share is nearly instantaneous. In WSL2, running the same command takes over 30 seconds. WSL2 is a massive hit to the seemless experience between the two operating systems with filesystem performance from Linux to Windows files orders of magnitude worse. Yes, unzipping tarballs or manipulating and stat syscalls are…

Clearly the best solution is for Microsoft to (a) write a proper ext4 driver for Windows and (b) find some way of embedding SIDs into ext4, then you could just format the drive as ext4, boot off it, and have the improved performance. (This is mostly a joke, but the performance of NTFS for certain operations has always been abysmal, and having a virus scanner injecting itself into all the operations only makes it wors…

AFAIK the main problem is that Unix's file permissions do not cover Windows' permission model. That would be tolerable on a data partition, but a system partition is going to use all kinds of very particular permission setups on system binaries etc.

You might be able to model that stuff as xattr, but then it could be problematic to mount that ext4 partition into Linux because applications might be copying files without respecting the xattrs.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#332
post #77

On a Win10 host, I want to edit code in sublime and have the runtime environment in linux. I want fast code search and fast build times. I've found no way to accomplish the above. Code in Windows + Windows Sublime means build in WSL will be slow because cross-os i/o Code in Linux + Windows Sublime means code search will be slow because cross-os i/o Code in Linux + Linux Sublime + Winodws Xserver means interface is la…

What Electron-related problems have you had with VSCode? I've been using it as my primary for a few years now and it's been nothing but stellar. And that integration sounds incredibly cool.

Not an Electron-related problem, just a general issue: What made me give up on VSCode after trying to make it work again(this March) was the fuzzy search just not being very good in my Rails projects. I can ctrl-shift-r in sublime and get to the method definition I want in 4-5 characters. It's probably my primary code navigation technique: see a thing, wanna check the def, 1-2 seconds later I'm there.

There's some VSCode extension that claims to mimic this but the fuzzy search seems much worse and it just doesn't quite work. Yes you can use the solargraph extension to sort of go to the def in vscode and it does all sorts of cool things, but I just never got into it.

It seems like a small thing but I just couldn't get over it, because I do it so often.

The main other difference is I much prefer the GitSavvy Sublime text extension to VSCode's built-in git handling. Particularly how I can see a summary of the commit I am making in GitSavvy whereas there doesn't seem to be a way to get all the file changes in one screen in VSC(though to be fair I didn't look around much for a way to do this, there probably is an option somewhere).

That being said if fuzzy search was working the same as in Sublime, I'd probably switch to Code.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#333
post #41
post #7

I switched to WSL2 a month ago and it's been great. With WSL1 I'd regularly run into subtle compatibility problems but haven't seen anything like that with 2. Despite a handful of annoyances, the Win10+WSL2+Visual Studio Code Dev environment has been a lot more pleasant than OSX.

I never thought I’d say it but because of this exact setup with VS Code I’ve actually stopped using my MBP at home in favor of my desktop, which was really only built with gaming in mind. I’ve now gotten used to having all the extra computing power at hand and would struggle to go back to a laptop as my primary development machine.

I've stopped coding on my 2012 Macbook Air in favour of my desktop PC for similar reasons. The fact that my ports are shared between Windows and Linux makes the web dev I do a dream.

The new Terminal app is great too. I've got all the same split pane stuff that I rely on in iTerm, including useful keyboard shortcuts for switching between them and resizing them. I'm very impressed.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#334

In WSL1, running "wsl git status" on a moderately sized repo on an NTFS (Windows side) drive or SMB file share is nearly instantaneous. In WSL2, running the same command takes over 30 seconds. WSL2 is a massive hit to the seemless experience between the two operating systems with filesystem performance from Linux to Windows files orders of magnitude worse. Yes, unzipping tarballs or manipulating and stat syscalls are…

Tip: you get great performance by just installing and running Linux directly.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#335
I've been using WSL1 for a long time now and I am very happy with it.

The way I use it is to have all my files and project on windows FS and I code using windows software (VSCode, Eclipse) but when I build and test, I use WSL1, and I didn't feel that the performance was that bad since I have an SSD and I don't mind waiting for few more minutes to rebuild a project.

But the most important thing for me was that I didn't care about managing another file system. All my files are still on windows where I used to keep them, file sync and backups are working as expected, and I easily browse and edit these files on the Windows side.

For docker, I installed docker on Windows and hooked Docker CLI on WSL1 to it using some configurations. and I was happy with it.

The question is, for the way I use WSL1, will WSL2 be an improvement or a drawback for me? and should someone like me switch to WSL2?

Re: Windows Subsystem for Linux 2 Moving into General Availability

#338
post #244

Earlier quoted context omitted.

> using the remote extension Then there is no WSL 2 handling in your editor. VSCode remote extension works in the same way for either WSL 2, or a full-fledged Linux VM, or even a remote Linux server. As someone who run a Linux VM side by side all times, I really don't get WSL 2.

You're just playing with the words here... It's the same as saying: " As a person who runs containers all the time, I really don't get Docker". The point is VS Code handles my code hosted in WSL 2 out of the box. I don't care that I could use a VM or a remote server instead. I just suggested that the parent commenter waits for is IDE to implement a similar integration...

Sorry, should have made my point more clear.

VSCode made some unique design choices which enable them to support connecting to any Linux server, VM or not. In contrast, these design choices may not be possible for other IDEs. So, because WSL 2 is, effectively, a Linux VM, supporting it in editor is harder than supporting WSL 1.

As for "I really don't get" part, I wanted to say that WSL 2 sounds like a regression to me, WSL 1 makes it possible to achieve something (namely, local-ish cross-"os" net/process/file-system integration) that is entirely impossible otherwise, while WSL 2 is a nice packaged-up solution but functionally does not do more than people already get (Hyper-V).

Re: Windows Subsystem for Linux 2 Moving into General Availability

#339

Earlier quoted context omitted.

The integration is very impressive, latest builds even have access to the WSL2 file system from Windows. Starting up VS Code on a machine with WSL2 immediately gives you the option to use it as the VS Code environment, it is pretty great.

Integration is even tighter now its not just a VM like many commented here.

Can you write a single feature that's available in WSL 2 but not in VirtualBox?

Re: Windows Subsystem for Linux 2 Moving into General Availability

#340
post #187

Earlier quoted context omitted.

why not use git natively? I've never understood why people use git in WSL since the IO performance isn't great

Unfortunately Git on Windows is also extremely slow. Especially using Magit in emacs, which does a lot of git calls, works much, much faster for me if it's sshing to a Linux VM for each call then running natively on Windows.

Git is not slow for me. Don't know about Emacs, but I'm using git from command line and from Idea and it works just fine, instantly for ordinary tasks. Commiting 1000+ files takes few seconds.

Given the fact that Git is used for Windows development with monster monorepository, I think that something's wrong with your setup rather than Git on Windows in general.

Post reply on HN