Windows Subsystem for Linux is not open source
4creators opened this issue · 13 comments
Excitement and interest created by Build announcement of "Bash on Ubuntu on Windows" Windows feature indicates great interest from OSS and Linux community in the project. I am convinced that Microsoft could expectd that community would provide helping hand in WSL development what based on experience with other MSFT open source project like .NET Core stack would be mutually beneficial. I personally see a great potential for new functionality like cross platform workloads running on single windows kernel or due to unexpectedly high performance in CPU/Memory bound tasks a lot of applications in scientific computing or in general HPC systems (see benchmarks by Phoronix - The Performance Of Ubuntu Software Running On Windows 10 With The New Linux Subsystem). One could imagine running different file systems as part of WSL i.e. ZFS or easily extending WSL support to other *nixes or Linux distros.
Possibilities are countless and allowing Linux hackers to participate would be great selling point for OSS community.
There is a proposal on Windows Uservoice so anyone can upvote it - Make Windows Subsystem for Linux Open-Source .
See #1
Missed that one :) probably bcs it has been closed. I think it is not the best idea to close discussion on that issue here as github seems to be significantly better platform to discuss it. I would rather follow .NET issue tracking policy here rather than delegate all of it to UserVoice forum.
@4creators - this is going to sound bad on my part, but I have not been able to find anything about .NET's issue tracking policy. Is there something written down?
More than happy to follow a set of rules the community knows and likes.
@russalex - I think that way .NET projects have created informal issue handling policy evolved over time based on my observations - it's practice based without any formal documents - I have watched several of projects as a subscriber for almost two years. Essentially they have divided issues into categories which are assigned a label i.e. Feature request, bug, etc. etc. - currently they use dozens of labels. The set of labels describes the scope of problems which can be raised in issue tracking system. They can be divided into categories like features, milestones, bugs, tests, performance goals and by using linking between them you are capable to create relations like bug blocking release candidate 2. In my opinion the best way to look at this it would be to read labels of .NET Core, Roslyn or CoreFX projects, than some documentation on contributing and derive from this some subset which is meaningful for Your project. I see labels as a set of graph nodes and relations as graph edges. If you connect it with product roadmap it creates very clear and easy to understand issue tracking system and project management tool. Than of course one has at his disposal all tooling provided by github to manage this.
Thread is an old one.
Since then we have implemented the labeling scheme. Hopefully this promotes some additional visibility into our thinking. Also added the high priority features here (read: things we are focused on for the Anniversary Edition). I'll give more information when we have it.
Discussion has been inactive for a while. Please feel free to re-open / add more comments if anything new comes to mind.
Closing out to keep the issues clean.
@russalex : Isn’t lxcore.sys basically a stripped Linux kernel ? If yes, in that case we can be sure it shares nothing with the original one (like the original ᴠꜰꜱ api) since the licence is ɢᴘʟ (forcing all forks like Webᴏꜱ to publish their source code)
Am I right ?
Lxcore.sys is a clean room implementation of the Linux kernel ABI. It contains no code from the Linux kernel and we have a policy that our developers cannot even look at any of the kernel source.
There is a blog post on the WSL architecture by @dethoma here. It is a great place to find more information on how the subsystem works. The blog talks a little about how syscalls are handled and how we can do all of this without looking at the Linux kernel code. @stehufntdev also has a very informative blog that deep dives on the system calls if you're curious. That blog is here.
@russalex Spencer McIntyre found a fun implementation-specific thing you guys did with memory mapping, and how sending invalid flags in Linux is ignored while in WSL they return an error message. Exactly the kind of quirk you would expect when the programmers are working from a spec. =]
Thanks for the feedback. We noticed that difference as well in testing but left the WSL behavior since it wasn't breaking any known scenarios. The WSL behavior will likely have to be changed eventually but with memory management syscalls we've found it's better to fail early than let the process limp along and fail in a spectacular way much later in an unrelated code block :).
@stehufntdev turns out that doing it your way protects against installation of some metasploit modules, so don't rush too much lol.
This issue was solved, before started: https://www.cygwin.com/