Earlier quoted context omitted.
The actual advantage of working on something like WSL1 is that it would ensure that the NT kernel is as capable as the Linux kernel (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels). For instance, the complaints about I/O performance are because the NT kernel has a worse implementation, so they should have improved it for both Win32 and Linux ap…
As I understand it, it's not really possible to "improve" Win32 I/O performance -- both the fundamental I/O APIs and the NTFS on-disk storage format make high performance infeasible. Not without either abandoning all extant FS drivers, or abandoning NTFS compatibility, anyway. Edit: Here are the WSL 1.x's team members original comments on this subject. It sounds like a deeply intractable problem. https://github.com/m…
Windows Subsystem for Linux: The lost potential
121–130 of 250 posts
Re: Windows Subsystem for Linux: The lost potential
#122Re: Windows Subsystem for Linux: The lost potential
#123Earlier quoted context omitted.
why would you need that if you have the command line functionality already? Windows has shipped with sftp for a while now. about the only think missing is a stand alone ssh client on the windows side but for that there is putty.
There is a native ssh client in windows 10. https://docs.microsoft.com/en-us/windows-server/administrati...
Re: Windows Subsystem for Linux: The lost potential
#124Earlier quoted context omitted.
Yes this feature is only available on Insiders builds for right now!
Thank you for your work on this project. Although like the author I have some reservations about moving to a virtualization-based approach, nonetheless I am grateful attention is being paid to these kind of technologies at all. WSL has totally changed my development workflow for the better.
Re: Windows Subsystem for Linux: The lost potential
#125Earlier quoted context omitted.
I see, that makes sense! This is a really interesting design and seeing it this way gives me more respect for the Windows operating system generally. Is this subsystem concept something that has a parallel on the *nix/BSD side of the fence? Or is it unique to the NT architecture?
The closest example outside Windows I can think of is the idea of "zones" in Solaris/Illumos/SmartOS. You can have a "LX branded zone" where the OS will respond to linux syscalls. I don't know if the native solaris syscall interface is itself a zone, while Win32 is a subsystem on Windows.
Re: Windows Subsystem for Linux: The lost potential
#126Earlier quoted context omitted.
I agree with the sentiment but, some scenarios have become orders of magnitude more complicated on WSL2 like connecting to a daemon on Windows or vice versa. I understand clear cut security boundaries and separate network interfaces, but it's extremely hard to get them running smoothly now. Everything was on localhost on WSL1. Memory usage has also gone bonkers with the VM approach, causing unnecessary overhead for c…
FYI to any WSL2 users, in it's migrated configuration the WSL VM can request as much RAM as it needs, but has no means to free this back. There's an option to use .wslconfig to specify a limit. https://github.com/microsoft/WSL/issues/4166
Re: Windows Subsystem for Linux: The lost potential
#127This article is entirely wrong about why it's called the Windows Subsystem for Linux and not the Linux Subsystem for Windows (not surprising, since his argument makes no sense). The real reason is that Microsoft can't name something leading with a trademark owned by someone else. Here it is straight from the horse's mouth, senior PM of WSL Rich Turner: https://twitter.com/richturn_ms/status/1245481405947076610
I'd never actually read it with the apostrophe as pointing out in that tweet so the name makes a lot more sense now. Perhaps Windows Subsystem for (running) Linux would be clearer hah
Also, according to his profile, Rich is former Product Manager for WSL and currently "Sr. PM for the Windows Command Line, Windows Terminal"
The interpretation in the article was still interesting nonetheless
Re: Windows Subsystem for Linux: The lost potential
#128I have zero insight obviously but I still believe it was ptrace that broke the camels back. And yes, I had so much hope for WSL1. > ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted) Issues also exist for PTRACE_O_TRACEEXIT, PTRACE_O_TRACEEXEC, PTRACE_OLDSETOPTIONS, PTRACE_SYSEMU.
It seems like those bugs were fixed some time ago. See: https://github.com/microsoft/WSL/issues/555
This makes lldb and dlv both just not work in wsl1 and that's just the languages I dabbed in, I think the Swift debugger had issues as well.
Re: Windows Subsystem for Linux: The lost potential
#129I want fish as my shell. Easy peasy. I want to type ‘code ‘ and have it open in VSCode. Can’t.
Re: Windows Subsystem for Linux: The lost potential
#130Earlier quoted context omitted.
It seems like those bugs were fixed some time ago. See: https://github.com/microsoft/WSL/issues/555
The big one is https://github.com/microsoft/WSL/issues/2028 which is "fixed-in-wsl2" This makes lldb and dlv both just not work in wsl1 and that's just the languages I dabbed in, I think the Swift debugger had issues as well.