4 ms·

Yep. With WSL I can seamlessly access files from both Linux and Windows. I use the Terminal (Windows) and various Unix tools for a lot of stuff (compiling & te

by drey08 6y ago

Yep. With WSL I can seamlessly access files from both Linux and Windows. I use the Terminal (Windows) and various Unix tools for a lot of stuff (compiling & testing on Posix, objdump, debugging). And I use Windows GUI tools for editing (Sublime), diffing (BeyondCompare), and so on. I get the best of both worlds. But WSL2 file access in `/mnt/c/` is now unbearably slow. So I just stick with WSL1. From what I've read, Microsoft intends to support both WSL1 and WSL2 for the foreseeable future. So that's good.

tyingq 6y ago
"Microsoft intends to support both WSL1 and WSL2" I'm not sure I believe them. Maintaining a whole tricky "fake" kernel/translation shim must be a lot of work.
- frankc 6y ago
  You never know but as has been pointed out in different parts of this post, they have two different use cases in a sense. Windows developers who were using WSL1 aren't going to like the changes and i've heard a lot of complaints. However, people using primarily linux with windows as a nice shell with good hardware support and games are going to prefer WSL2. I think if they want to win over the biggest group of devs, and I feel pretty good about that since they were losing traction with them for years, they will maintain both, at least for a good while.
- drewg123 6y ago
  FreeBSD has a similar syscall translation layer (and has had it for over 20 years). They do it with a team of part-time volunteers. This is enough to maintain basic support, but FreeBSD still lack support for newer Linux syscalls which prevent things like the Linux binary version of Chrome from running on FreeBSD.
  - tyingq 6y ago
    Yes, but translating syscalls across two Unix like systems is likely much easier. Big parts of it even just straight mapping one number to another.
    - drewg123 6y ago
      This is somewhat true, but not entirely. You have to remember that FreeBSD and Linux share no common ancestors, and FreeBSD defines its ABI at the libc level, whereas Linux defines it at the syscall level. There are also subtle differences in how various internal kernel mechanisms work (such as flag definitions for calls). See linux_common_open() for an example of an "easy" straight mapping. https://github.com/freebsd/freebsd/blob/68a4c41e983228d54619ac5a6c170197eacd8c9b/sys/compat/linux/linux_file.c#L88 https://github.com/freebsd/freebsd/blob/68a4c41e983228d54619... This is true even between OSes that share a common ancestor. I was the maintainer of FreeBSD/alpha, and did the compat layer for OSF/1 / DEC UNIX / Tru64 starting with NetBSD's version and adding new calls, etc. The very easiest calls were the simple ones that both inherited from 4.3BSD or earlier (read, write). Medium were things that had diverged in different ways (stat, mmap), and for me the harder things were ABI handlers for the OSF/1 executable format (ecoff). The hardest stuff was things at almost worked, except for maybe one flag was different, and it was hard to notice because an OSF/1 program would run for 5 minutes, and then coredump.
      - tyingq 6y ago
        That's a great rundown. I didn't mean to oversimplify the effort. Just to say that mapping Linux to Windows is likely much harder. The lseek() call in your link is closer to what I meant by simple.
      - yjftsjthsd-h 6y ago
        > FreeBSD defines its ABI at the libc level, whereas Linux defines it at the syscall level Actually, this really does make it more impressive than I'd realized, especially since FreeBSD didn't just shim libc in - I've run an Alpine Linux (musl-based) chroot on FreeBSD and that worked, which it wouldn't have if they just made a glibc-like wrapper. (I think.)
- mehrdadn 6y ago
  > I'm not sure I believe them. I'm not sure why anyone should. They literally say "We currently have no plans to deprecate WSL 1" while simultaneously claiming "We are committed to making WSL 2 feel the same as WSL 1". There's no way their goal is to reach a steady state where they feel the same and yet both have to be maintained. Making them feel the same is literally what you do when your goal is to stop support for one of them. They probably just haven't "planned" it yet, unless they don't expect they will actually ever get them to feel the same.
  - yebyen 6y ago
    I watched Aaron Patterson's keynote from RailsConf 2020 (these talks all just came out this week, Couch Edition) and I'm struck when reading your comment that it's absolutely possible to do this, and ultimately you may or may not reach a state where it's possible to "end-of-life" one or the other alternative without making anyone cry about it. He spends most of the second half of the talk explaining (with a profiler) how two query implementations on ActiveRecord which should be doing pretty much about the same thing, actually perform wildly differently, and narrowing it down with data to understand why. The talk is really interesting and I think it's a parallel to the current discussion in a way because, in Aaron's talk there were two implementations and one was obviously better performing (but unfortunately it was the one that is harder to write.) He argued mostly that, unless there is a reason for these two implementations to behave and perform differently, the one that is slower (but easier to write) should become more like the one that is "enhanced with a performance pro-tip" that arguably the ActiveRecord user shouldn't really need to know about. In other words, that the bad performance was actually a bug. (tl;dr: the pro-tip is, to build your own pre-sanitized SQL WHERE clause strings, because you may save something like 38% performance in a pathological case, recovered time that the SQL engine was going to spend traversing AST and compiling.) My point is that, exactly. If there is bad performance over here, it is a bug. Bad performance over there, bug. But bad performance over here, that can only be solved by swapping for bad performance over there? This does not sound like a bug anymore, it starts to sound more decidedly like a trade-off. But given enough time, perhaps they will fix the bugs, and the two can be made to perform similarly, fixing bugs on either side, and the need for two alternatives will go away. So why would that be bad? (And if it can't be done, or can't be done yet, why wouldn't we expect to see both implementations maintained as long as needed to find a solution that pareto-dominates them both?)
d2161 6y ago
Why not just store files in WSL home directory? It's faster than accessing from mnt/c
- unicornfinder 6y ago
  Well it depends on your use case. If you're using WSL to develop web apps then storing it all in WSL is fine, but if you want to use Linux tools to process a load of files in your Windows drive then it's not quite as smooth sailing...
mattwad 6y ago
Check out VS Code. It can now read and edit files inside of WSL remotely [1]. I've been using it on a new project and it works almost seamlessly * . I don't know if other editors will get this functionality, but there's really no need now for me to save files in /mnt/c. [1] https://code.visualstudio.com/docs/remote/wsl https://code.visualstudio.com/docs/remote/wsl * One curious effect is you can't move folders from VS Code due to permissions. So I have to close it and use Windows Terminal for that, but moving folders doesn't happen too often.
nickjj 6y ago
Couldn't you do the reverse now with WSL 2? The files would live in WSL 2 directly, but then you access them over Windows through the WSL network path? I don't have insiders installed so I don't know how slow that would be. Like if you CTRL+p'd in Sublime Text, would it have to grab a list of files from over the network on every call, or does it cache these files locally on a per ST session basis, etc.. There's also maybe the option of running ST natively in WSL 2 and expose its GUI over an X-server. I know latency there is very good (near native) because I've done it in the past. This also gives you the added advantage of ST being able to know about your Linux environment which could be nice for linting and other things that require having your programming runtime installed in the same place as your editor. You can still have shortcuts too in Windows, for pinning stuff to your taskbar or having right click menus. I do this with Vim now with WSL 1, where I have a custom "open with Vim" right click menu in explorer that opens terminal / native Linux Vim that's installed in WSL.

by drey08 6y ago

tyingq 6y ago

"Microsoft intends to support both WSL1 and WSL2" I'm not sure I believe them. Maintaining a whole tricky "fake" kernel/translation shim must be a lot of work.

frankc 6y ago
You never know but as has been pointed out in different parts of this post, they have two different use cases in a sense. Windows developers who were using WSL1 aren't going to like the changes and i've heard a lot of complaints. However, people using primarily linux with windows as a nice shell with good hardware support and games are going to prefer WSL2. I think if they want to win over the biggest group of devs, and I feel pretty good about that since they were losing traction with them for years, they will maintain both, at least for a good while.
drewg123 6y ago
FreeBSD has a similar syscall translation layer (and has had it for over 20 years). They do it with a team of part-time volunteers. This is enough to maintain basic support, but FreeBSD still lack support for newer Linux syscalls which prevent things like the Linux binary version of Chrome from running on FreeBSD.
- tyingq 6y ago
  Yes, but translating syscalls across two Unix like systems is likely much easier. Big parts of it even just straight mapping one number to another.
  - drewg123 6y ago
    This is somewhat true, but not entirely. You have to remember that FreeBSD and Linux share no common ancestors, and FreeBSD defines its ABI at the libc level, whereas Linux defines it at the syscall level. There are also subtle differences in how various internal kernel mechanisms work (such as flag definitions for calls). See linux_common_open() for an example of an "easy" straight mapping. https://github.com/freebsd/freebsd/blob/68a4c41e983228d54619ac5a6c170197eacd8c9b/sys/compat/linux/linux_file.c#L88 https://github.com/freebsd/freebsd/blob/68a4c41e983228d54619... This is true even between OSes that share a common ancestor. I was the maintainer of FreeBSD/alpha, and did the compat layer for OSF/1 / DEC UNIX / Tru64 starting with NetBSD's version and adding new calls, etc. The very easiest calls were the simple ones that both inherited from 4.3BSD or earlier (read, write). Medium were things that had diverged in different ways (stat, mmap), and for me the harder things were ABI handlers for the OSF/1 executable format (ecoff). The hardest stuff was things at almost worked, except for maybe one flag was different, and it was hard to notice because an OSF/1 program would run for 5 minutes, and then coredump.
    - tyingq 6y ago
      That's a great rundown. I didn't mean to oversimplify the effort. Just to say that mapping Linux to Windows is likely much harder. The lseek() call in your link is closer to what I meant by simple.
    - yjftsjthsd-h 6y ago
      > FreeBSD defines its ABI at the libc level, whereas Linux defines it at the syscall level Actually, this really does make it more impressive than I'd realized, especially since FreeBSD didn't just shim libc in - I've run an Alpine Linux (musl-based) chroot on FreeBSD and that worked, which it wouldn't have if they just made a glibc-like wrapper. (I think.)
mehrdadn 6y ago
> I'm not sure I believe them. I'm not sure why anyone should. They literally say "We currently have no plans to deprecate WSL 1" while simultaneously claiming "We are committed to making WSL 2 feel the same as WSL 1". There's no way their goal is to reach a steady state where they feel the same and yet both have to be maintained. Making them feel the same is literally what you do when your goal is to stop support for one of them. They probably just haven't "planned" it yet, unless they don't expect they will actually ever get them to feel the same.
- yebyen 6y ago
  I watched Aaron Patterson's keynote from RailsConf 2020 (these talks all just came out this week, Couch Edition) and I'm struck when reading your comment that it's absolutely possible to do this, and ultimately you may or may not reach a state where it's possible to "end-of-life" one or the other alternative without making anyone cry about it. He spends most of the second half of the talk explaining (with a profiler) how two query implementations on ActiveRecord which should be doing pretty much about the same thing, actually perform wildly differently, and narrowing it down with data to understand why. The talk is really interesting and I think it's a parallel to the current discussion in a way because, in Aaron's talk there were two implementations and one was obviously better performing (but unfortunately it was the one that is harder to write.) He argued mostly that, unless there is a reason for these two implementations to behave and perform differently, the one that is slower (but easier to write) should become more like the one that is "enhanced with a performance pro-tip" that arguably the ActiveRecord user shouldn't really need to know about. In other words, that the bad performance was actually a bug. (tl;dr: the pro-tip is, to build your own pre-sanitized SQL WHERE clause strings, because you may save something like 38% performance in a pathological case, recovered time that the SQL engine was going to spend traversing AST and compiling.) My point is that, exactly. If there is bad performance over here, it is a bug. Bad performance over there, bug. But bad performance over here, that can only be solved by swapping for bad performance over there? This does not sound like a bug anymore, it starts to sound more decidedly like a trade-off. But given enough time, perhaps they will fix the bugs, and the two can be made to perform similarly, fixing bugs on either side, and the need for two alternatives will go away. So why would that be bad? (And if it can't be done, or can't be done yet, why wouldn't we expect to see both implementations maintained as long as needed to find a solution that pareto-dominates them both?)

d2161 6y ago

Why not just store files in WSL home directory? It's faster than accessing from mnt/c

unicornfinder 6y ago
Well it depends on your use case. If you're using WSL to develop web apps then storing it all in WSL is fine, but if you want to use Linux tools to process a load of files in your Windows drive then it's not quite as smooth sailing...

mattwad 6y ago

Check out VS Code. It can now read and edit files inside of WSL remotely [1]. I've been using it on a new project and it works almost seamlessly * . I don't know if other editors will get this functionality, but there's really no need now for me to save files in /mnt/c. [1] https://code.visualstudio.com/docs/remote/wsl https://code.visualstudio.com/docs/remote/wsl * One curious effect is you can't move folders from VS Code due to permissions. So I have to close it and use Windows Terminal for that, but moving folders doesn't happen too often.

nickjj 6y ago

Couldn't you do the reverse now with WSL 2? The files would live in WSL 2 directly, but then you access them over Windows through the WSL network path? I don't have insiders installed so I don't know how slow that would be. Like if you CTRL+p'd in Sublime Text, would it have to grab a list of files from over the network on every call, or does it cache these files locally on a per ST session basis, etc.. There's also maybe the option of running ST natively in WSL 2 and expose its GUI over an X-server. I know latency there is very good (near native) because I've done it in the past. This also gives you the added advantage of ST being able to know about your Linux environment which could be nice for linting and other things that require having your programming runtime installed in the same place as your editor. You can still have shortcuts too in Windows, for pinning stuff to your taskbar or having right click menus. I do this with Vim now with WSL 1, where I have a custom "open with Vim" right click menu in explorer that opens terminal / native Linux Vim that's installed in WSL.