Windows Subsystem for Linux: The lost potential
1–10 of 250 posts
Re: Windows Subsystem for Linux: The lost potential
#2It would be wonderful if sftp was included in windows distributions natively
Re: Windows Subsystem for Linux: The lost potential
#3It would be wonderful if sftp was included in windows distributions natively
but it is included, as well as scp
Re: Windows Subsystem for Linux: The lost potential
#4> And the reason I can imagine this is because macOS gives you this model (albeit cheating because macOS is essentially Unix).
What is the cheat there? That MacOS X is a single operating system, where both, command line tools the blog author knows and GUI tools, life in the same world, with da process model and same devices on a single kernel, unlike WSL? How is that cheating? Is my Linux desktop cheating as well?
Re: Windows Subsystem for Linux: The lost potential
#5I've dedicated 2 solid work hours to help a co-worker migrate from wsl1 to wsl2.
Such a PITA. I couldn't get the linux tab to appear on his explorer.exe like in mine but oh well everything else worked fine!
Re: Windows Subsystem for Linux: The lost potential
#6I think we all are sometimes guilty of reading too much into things. WSL was announced to support developers. Not Administrators. The Windows/Azure division has a strategy for administration. And that is Powershell (also on Linux). They admin strategy is implement Powershell commandlets for Windows and Linux and execute them via Powershell (and things like DSC).
WSL however was always announced as a tool for developers to develop stuff. As long as you can run Linux tools and services and finish your dev tasks with it, they are considering it as goal achieved.
Re: Windows Subsystem for Linux: The lost potential
#7> And the reason I can imagine this is because macOS gives you this model (albeit cheating because macOS is essentially Unix). What is the cheat there? That MacOS X is a single operating system, where both, command line tools the blog author knows and GUI tools, life in the same world, with da process model and same devices on a single kernel, unlike WSL? How is that cheating? Is my Linux desktop cheating as well?
cheating as in they have much less work to do to implement unix-like linux on the hood because it was already there, and Microsoft actually has to build a port.
Re: Windows Subsystem for Linux: The lost potential
#8Re: Windows Subsystem for Linux: The lost potential
#9Contra opinion: the VM option reduced the service interface between Windows and Linux to a single kernel implementation and a few drivers, rather than every possible userspace program ever written. It's an amazing and obvious trade off. My inner architecture astronaut appreciates all the ideas in this post, but I've been trying to kill that guy for over a decade now. The bottom line is WSLv1 design SUCKED precisely because it tried to cross-breed 2 extremely complex semantically incompatible systems.
Example: Linux local filesystem performance mostly derives from the dentry cache. That cache keeps a parsed representation of whatever the filesystem knows appears on disk. The dentry cache is crucial to pretty much any filesystem system call that does not already involve an open file, and IIRC many that also do. Problem is, that same cache in WSL must be subverted because Linux is not the only thing that can mutate the NTFS filesystem - any Windows program could as well. This one fundamentally unfixable problem alone is probably 80% the reason WSL1 IO perf sucked - because the design absolutely required it.
Solutions are rip out a core piece of kernel functionality, and in the process basically taking over ownership and maintenance for ALL code anywhere in the kernel assuming the existence of said cache, engineer something that is somehow better, and support this in perpetuity, including any semantic mismatches that turn up much later that were never designed for
The idea of merged ps output where Windows binaries would show up in the Linux /proc. How would you even begin to implement that without confusing EVERY process management tool ever written that interfaced with /proc? What about /proc/.../environ? On UNIX that has no character set. On Windows it is Unicode.
A trillion problems like this made WSL1 a beautiful nightmare. Glad it was tried and from watching the tickets, that team bled heroically trying to make it all work, but ultimately, I'm also glad it's gone, because the replacement is infinitely easier to engineer, maintain, and use, and that team earns its quarterly bonus much more easily. Everyone wins, except the astronauts, but as experience teaches us they never do.
Re: Windows Subsystem for Linux: The lost potential
#10This is a really interesting article, and WSL 1 was a testament to Dave Cutler's vision for the NT architecture re: support for multiple operating environments (read 'Showstopper!' for more background).
Also, as someone hacking with a custom OS kernel in their spare time, I found this quote illuminating when it comes to understanding the lower level:
> A user-space process is a collection of binary instructions that the processor executes uninterruptedly (leaving interrupts aside). The operating system’s kernel is unaware of what the process is doing until the process issues a system call: at that point, the kernel regains control to perform an operation on behalf of the user, which can be something like reading a file or pausing for a few seconds.
[Edit: My first point is actually incorrect - see child comment about 'pico processes']